[RFC] GTK+ 3 Migration - Alpha-grade Patchset

Derek Atkins derek at ihtfp.com
Wed Feb 24 16:37:39 EST 2016


On Wed, February 24, 2016 4:26 pm, Christian Stimming wrote:

> I agree that porting from GObject to C++ is a step forward. However, by
> now I
> have my doubts whether that effort is actually well invested anymore.
> Geert,
> are you sure we said C++ would help in "portability to mobile platforms"?
> For
> an android app, it is useless to have "the engine" in C - one needs it in
> Java
> anyway, and that's why Ngewi wrote a re-implementation of our data
> structures
> in Java for his gnucash-on-android app.

Yes, it will help.  If the engine were purely in C++ (without Glib) then
we could have just build a JNI layer around that to plug into an Android
UI.  This is actually relatively straighforward -- even moreso if it's a
nice C++ interface.

This didn't work with the existing engine because of the "too many
external dependencies" issue; he would have had to port glib to Android.

>       I don't think a plain C++(11) plus
> some boost dependencies would actually help anything when moving the app
> to a
> mobile OS. Instead, C++ just tries to make the further development of the
> desktop application somewhat more realistic. But there is just such a
> large
> amount of code...

Honestly I think it would help; the issue (in my mind) is the underlying
dependencies under the engine.  If we can remove glib, guile, and other
dependencies and leave it purely at C++ (and arguably boost), I think it
would go a long way to making it easier to port the engine to alternate
platforms like Android and iOS that would require their own UIs.

It does beg the question of whether this is a reasonable goal.  Do these
devices need to interoperate with the desktop gnucash data files?

> Regards,
>
> Christian

-derek

-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant



More information about the gnucash-devel mailing list