Future of Gnucash

John Ralls jralls at ceridwen.us
Tue Dec 28 11:50:22 EST 2010


On Dec 28, 2010, at 6:52 AM, Phil Longstaff wrote:

> The subject sounds a bit ominous, but I don't mean it to be.
> 
> 2.4.0 is now out the door.  Already there are ideas rolling in about the
> next enhancements.  I was just about to tackle one of the enhancements
> when instead, I thought I would (again) raise a broader issue.
> 
> A few months ago, Christian Stimming started CuteCash with the aims of
> replacing gtk by Qt/C++.  The idea was that development in gtk/C was too
> slow and cumbersome.
> 
> So, the big question is: should we set a direction to have CuteCash
> replace GnuCash, and if so, what are the steps/milestones to get there?
> 
> Obviously, since this is all open-source, it's not either/or.  One group
> could continue with GnuCash as it is while the other develops CuteCash.
> Personally, I like the idea of CuteCash and would prefer to develop for
> Qt/C++ rather than gtk/C.  On the other hand, until CuteCash catches up
> in features to GnuCash, if I want any new functionality, it has to go
> into GnuCash.
> 
> So, among the questions I will raise:
> 1) Does the current set of engine objects make sense?  They currently
> are gobjects and CuteCash has C++ wrappers.  I guess they need to stay
> that way until CuteCash replaces GnuCash, at which point the C++
> wrappers could become the official public API.
> 
> 2) Does QOF still make sense?  Back in the earlier days of the SQL
> backend, there was a proposal to replace qof with libgda (gnome data
> access layer) which might be a step toward gnucash as a database app.
> 
> 3) Should I hesitate to introduce new gobjects?  One thing I want to do
> is replace the current preferences with a better system for managing
> global vs per-file preferences on a system vs per-user basis.  My idea
> is a GncPrefs gobject interface with
> get_int()/set_int()/get_string()/set_string()/... functions.  These
> could be implemented to use gconf on linux, the registry on windows, etc
> to better tie into native preferences systems.
> 
> My preference is to work on the under-the-covers stuff and leave the
> UI/functionality to others.  Christian, do you have a roadmap for
> CuteCash to help it catch up to Gnucash in functionality?


I'd much prefer C++ to GObjects, but either is better than the GObjects without the G that you used for the dbi/sql backend. We can make the transition gradually, as C++ and C inter-operate nicely.

If we get the UI code properly separated from everything else, then we can support more than one GUI framework. We can do that gradually, too, writing new UI code in C++ for Gtkmm.

Qof will have to go if we're going to do records-on-demand and push the relational logic into the database  where it belongs, but we still need some sort of abstraction layer between the "business logic" (I hate that term, but I don't know a better one that communicates the same idea) and the storage layer. Libgda has a C++ interface, so that's a possiblity, but I wonder if it really adds that much over just writing objects with serialization/deserialization methods.

The deeper question is whether to keep the other Gnome and Glib dependencies. We've got a major porting job ahead of us even if we do stick with Gtk+ because we're still using a bunch of Gnome libraries that are going away in Gnome-3. In general the instability of the Gtk interface (there's always a new idea, and off they go in a new direction... look at how Gtk+ has changed in the last 3 months even though they're supposed to release 3.0 in January) is at odds with our goal for being able to operate across several years worth of distributions. 

Regards,
John Ralls



More information about the gnucash-devel mailing list