Beyond 2.6 (was:Re: Gnucash 2.5/6)

[Christian Stimming]

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

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

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.

Regards,

Christian