Ditching Gtk (was r19673 - gnucash/trunk/src/backend/sql )

[John Ralls]

On Oct 19, 2010, at 7:59 AM, Geert Janssens wrote:

> On Tuesday 19 October 2010, John Ralls wrote:
>> You raise a very valid point. Mixing the gui into the  isn't a good
>> long-term approach, especially if we're going to dump Gtk anyway. On the
>> other hand, the backend already uses gopbject pretty extensively and that
>> is all going to have to be redone in C++ (or come other OO language, but
>> C++ will be easiest) if we're going to get away from Gtk.
>> 
> I'm not sure if all has to be redone in C++ or another OO language. At least 
> not necessarily in the same refactoring phase. My understanding was that even 
> Cutecash would initially only focus on an enhanced gui on top of the current 
> qof/gobject based engine.

No, not all in one refactoring: It's a major undertaking.  It might be too hard to be worthwhile. But ISTM that there's not a lot of point to a GUI port if the backend is still so heavily dependent on Gnome facilities, which dependencies make up the bulk of a standalone Gnucash. 

We're going to have to rewrite a lot of the backend anyway, though, because many of those Gnome facilities are going away. In some cases it's because similar facilities have been pushed down into glib or gtk (libgnome, gconf). Others (gnome-vfs) have been replaced with different implementations having other names, and several (bonobo, anything ORB) have been declared stupid and thrown out. If we write the new code so as to keep the dependencies at arm's length we can have a program that is toolkit-agnostic. With that in hand, having multiple frontends begins to make some sense.

We could even keep the glib/gobject underpinnings if we must, though using a proper OO language is much easier to write and to maintain than gobject's stupid "real men do their OO in pure C" hacks.

All of which is completely irrelevant to getting 2.4 shipped.

Regards,
John Ralls