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

[John Ralls]

On Feb 8, 2013, at 8:01 PM, John Ralls <jralls at ceridwen.us> wrote:

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

Having argued that C++ in the backend in not such a big deal, I'm going to turn around and point out that
dropping Gtk+ in favor of wx, Qt, or some other GUI framework isn't a easy job: That *is* a complete rewrite,
and there's a lot of it.

Who would do it?

Regards,
John Ralls