Beyond 2.6

John Ralls jralls at
Tue Feb 12 10:33:13 EST 2013

On Feb 12, 2013, at 3:42 AM, Geert Janssens <janssens-geert at> wrote:

> On 12-02-13 12:22, Buddha Buck wrote:
>> On Tue, Feb 12, 2013 at 4:21 AM, Geert Janssens
>> <janssens-geert at> 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.
> Indeed. I mostly meant to suggest our *engine* should be totally multi-platform. The gui should be adapted to the target OS and form-factor anyway. I wouldn't want to use a gui similar to current GnuCash's one on an Android tablet for example. Having the engine available on say Android, that could make Ngewi's work a lot easier: instead of importing/exporting, he could plainly open a real gnucash datafile and work directly on it. That doesn't mean the GnuCash on Android tool should support all the features GnuCash on Linux/OSX/Windows does, but it would be able to properly load and save the file without any data loss.


>> 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.
> True. And I sometimes get the feeling all GUI work is slowly converging on this standard. Gtk has an experimental HTML backend, we're seeing ChromeOS, FirefoxOX, even QML is inspired on the same declarative concept if I remember well (though it is not HTML in itself).

HTML5 isn't a UI framework, it's a canvas like Cairo. Unless you want to write the code to draw every UI element and behavior, you need a higher-level toolkit like Gtk or Qt that's implemented on top of 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.

Apple's softened on that, but the way we use Guile now -- for report generation -- is eminently disposable. A bigger obstacle might be our license: The GPL is in conflict with the App Store terms of service. 

Anyway, this is distant future stuff. Let's get to work on what we need for 2.6.

John Ralls

More information about the gnucash-devel mailing list