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

[Christian Stimming]

Am Tuesday 19 October 2010 schrieb 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.

Just to confirm this once again: The cutecash experiment compiled already with 
all backends, but no gtk. I'm happy to hear you have already fixed the 
temporary workaround so that the backend (now) continues to stay without gtk 
dependencies.

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

When I wrote the first cutecash version (the 4000 lines of code now in 
src/gnc/*), one of my intentions was to check which parts of glib/gtk/gnome 
are actually needed if another frontend re-uses the existing backend code. I'm 
happy to report that the backend code really don't need anything else besides 
the following:

 glib 
 gconf
 gobject
 gmodule
 gthread
 libxml2
 zlib
 libintl

In particular, neither libgnome nor gnome-vfs nor bonobo are needed by the 
backend, not to speak of gtk. See src/gnc/CMakeLists.txt at the end for the 
libraries which *are* needed in the resulting cutecash qt4 executable.

So: The result of the first cutecash attempt confirmed that the backend code 
is re-usable even with completely different frontends without drawing too much 
gtk stuff into the executable.

> All of which is completely irrelevant to getting 2.4 shipped.

This is completely true, too.

Thanks!

Christian