Future of Gnucash: Most productive platform (programming language and toolkit)?
mta at umich.edu
Wed Dec 29 02:28:46 EST 2010
--On December 28, 2010 6:09:59 PM -0800 John Ralls <jralls at ceridwen.us>
> 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
> thanks to gobject-introspection (assuming that it works as
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.
More information about the gnucash-devel