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

[John Ralls]

On Feb 8, 2013, at 1:03 PM, Christian Stimming <christian at cstimming.de> wrote:

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

I thought that you'd found more gainful employ. ;-) Hope it's working out well for you.

Agreed, we will at some point have to deal with signals, but there's plenty of engine and backend stuff that
can be reimplemented before that. There are also a Boost signals/slots libraries. My main near-term interest
is in replacing the rather arcane and verbose GObject typing, construction, destruction, and reference
counting with the easier to write and more readable C++ equivalents.

As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're dumping Gtk+ because we don't 
like the direction they're going, Gtkmm doesn't get us anywhere.

Regards,
John Ralls