Future of Gnucash: Most productive platform (programming language and toolkit)?

[Colin Law]

On 29 December 2010 07:28, Mike Alexander <mta at umich.edu> wrote:
> --On December 28, 2010 6:09:59 PM -0800 John Ralls <jralls at ceridwen.us>
> wrote:
>
>> There are two drivers for reimplementation:
>>
>> 1. One of our goals for 2.6 is to enable multiple simultaneous access
>> to a dataset. In order to get there, large swaths of existing code
>> need to be rewritten to interact directly with the database backends
>> instead of sucking everything into memory when the program starts up
>> or the user switches datasets. That code is written partly in
>> ordinary C and partly in sort-of object oriented code using the Gnome
>> GObject library. I don't know if either you or Donald have ever
>> worked with GObject, but it's quite painful.
>>
>> 2. Gtk+-3.0 is supposed to be released next month. It removes a bunch
>> of libraries which have been deprecated for several years upon which
>> Gnucash at present depends. All code that depends on those libraries
>> needs to get rewritten or we're not going to be in a bunch of distros
>> by the end of 2011, possibly starting with Ubuntu 11.04 in May. Other
>> distros (chiefly Debian and Red Hat Enterprise) will probably not
>> update to Gtk+-3 for a couple more years, meaning that we're going to
>> have to either maintain a separate Gtk+-2.0 branch or switch to a
>> different GUI framework even if we accept leaving all the existing
>> installations on 2.4 (which Jeff Warnica advocated). Again,
>> everything Gtk+ touches is written in C with GObjects. It can be done
>> more easily in C++ or Python -- or, for all I know, Javascript --
>> thanks to gobject-introspection (assuming that it works as
>> advertised).
>
> These are both good reasons to consider moving some of the code to C++. If
> we're going to have to rewrite a bunch of stuff anyway, then do it in a more
> structured language.  No matter how you look at it, this is a really big job
> for a volunteer project.
>

I know little about the internal structure of GnuCash, having only
dabbled at the edges a little, but I would like to suggest that an
important area to consider is the separation of the back end logic
from the UI.  There are already regular requests to use GnuCash from
mobile devices and I venture to suggest that in a year or two the
ability to use the software from a mobile device (possibly with the
database on ones home PC) will be considered essential by many users.
To achieve this maybe some sort of web interface will be necessary.
There are many imponderables to this but the first step may be to
separate out the UI and provide an interface that an alternative front
end can connect to.

Colin