Beyond 2.6 (was:Re: Gnucash 2.5/6)
christian at cstimming.de
Fri Feb 8 16:03:10 EST 2013
Am Freitag, 8. Februar 2013, 09:51:57 schrieb John Ralls:
> >>> Personnaly I'd rather see us move to Qt instead of Gtk3 when that
> >>> decision has to be made.
> > I did express my interest in Qt before in mails to the list.
> > But when you also want to switch to C++ and Boost, to me that sounds
> > more or less like a complete rewrite of GnuCash. We've had this
> > conversation before, and more or less came to the conclusion we don't
> > have enough man power to do that.
> > Unless such rewrite can be done in baby steps, spread over several
> > releases, say like one module at the time ? Is such a segmentation
> > possible/practical ?
No, switching from C/gtk to C++/whatever in minor steps is in general not
When talking about gnucash in C++: Please, don't only make your guesses, but
also compile the "cutecash" part once. There were already some conclusions as
for the possibility of going to C++:
The choice of "C++" is not sufficient; additionally, the GUI toolkit must be
chosen as well. Qt was mentioned, but gtkmm is possible as well and maybe even
The toolkit choice sets the requirement for the event signaling that is
needed. Qt has its own signals; gtkmm has GObject signals wrapped in some C++
magic (IIRC). Gnucash/qof has the weird gnucash signals that we hope to get
rid of sometime in the future.
Trying to mix'n'match the toolkit and signalling frameworks does not work
rather well. The cutecash code is Qt but needs to have the signal/slot
adapters for our gnucash signals, but they suck. Trying to get Qt widgets
receive GObject signals in general should probably be possible, but I haven't
found a good implementation last time I checked.
> C is mostly a subset of C++, so a lot of the work is just renaming and
> fixing headers.
As I said: The language itself is not a sufficient choice. Only stating "we
want C++" but not choosing a C++ toolkit and signalling framework buys us
nothing, because in that case the signals must be written as C function and
macro thingies which do not look nice anymore if we're using C++.
On the other hand, the code in src/optional/gtkmm/gncmm is already a usable
C++ wrapper for the first few business-code classes, using gtkmm and sticking
to the gnucash signals, and it works correctly in the cutecash application.
This can be used as a basis to do more C++ evaluation.
Having said all this, I also have to admit I most probably won't do any work
in this direction or in any other direction, as my time budget for gnucash has
now gone to zero due to real life work... but the ideas are still there.
More information about the gnucash-devel