Beyond 2.6

Buddha Buck blaisepascal at gmail.com
Tue Feb 12 06:22:12 EST 2013


On Tue, Feb 12, 2013 at 4:21 AM, Geert Janssens
<janssens-geert at telenet.be> wrote:
> My peronal interest is simplified multi-platform support. If we can achieve
> that by slowly moving away from GLib/GObject by using C++ I welcome that as
> well. I don't mind it will take me some time to get used to C++. The
> language in itself interests me for a variety of reasons.
>
> To be clear on this: for me multi-platform support extends beyond Linux,
> Windows and OS X to also the new mobile OS's like Android and IOS. We
> currently don't have much there other than the nice helper app by Ngewi Fet.
> But it's totally independent. Much more could be possible if our pure engine
> were portable to all those platforms. The GUI and the features exposed by it
> can be platform specific. And I'm aware that C++ is not Java (for Android),
> but many C(++) applications are being ported to Android successfully using
> the Android's NDK, so IMO this is realistic for the long term. I have never
> looked into IOS, but probably similar things will be possible there (if not
> vetoed by all-too-mighty Apple).

A lot more work than just moving to C++ is necessary for that level of
multi-platform support.  Both Android and iOS have native UI engines
and neither support Gtk+ or Qt very well.  What would work is to write
as much of the code to be not dependent on any particular UI engine as
possible, and have 3 separate (desktop, Android, iOS) UI layers tuned
to each platform.

There is one cross-platform UI engine which is well-supported on all
platforms (Windows, Linux, Mac, Android, iOS) that I can think of, but
utilizing it would require a more major change in the structure of the
code: HTML5.

> For this improved multi-platform support, I think we need another
> refactoring in the engine: we should get rid of the guile dependencies in
> there. I think it's ok to have the engine wrapped in guile, but the engine
> core functions shouldn't depend on code written in guile.

That seems like a good idea; Apple doesn't like 3rd-party scripting
languages on iOS.


More information about the gnucash-devel mailing list