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

[John Ralls]

On Dec 28, 2010, at 5:03 PM, Mike Alexander wrote:

> --On December 28, 2010 10:27:48 PM +0100 Christian Stimming <stimming at tuhh.de> wrote:
> 
>> It seems to me my C++ experiment (as I would call it) has still not
>> yet been  understood the way I thought, so I'll elaborate a bit on
>> what I did and what  my conclusions are. Incidentally, I'm a
>> scientist. If I make some claim, I  better get some arguments
>> together that support it.
> 
> In a previous job I was part of a group that reimplemented a significant part of an XML editing and publishing application that consisted of several million lines of mostly C code in C++.  My experience with this agrees almost entirely with Christian's comments. The GUI is hard, modern tool kits and languages make it a lot easier, but it's still hard.  Unless there is some other reason to reimplement things it probably isn't worth the trouble.

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).

Regards,
John Ralls