Beyond 2.6

David Carlson carlson.dl at sbcglobal.net
Fri Feb 8 18:12:09 EST 2013


On 2/8/2013 3:03 PM, Christian Stimming 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.
>
> Regards,
>
> Christian
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
Also please keep in mind your goals regarding database filetypes.

David C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDC7C8BF3.asc
Type: application/pgp-keys
Size: 1729 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20130208/a308dbb2/attachment.bin>


More information about the gnucash-devel mailing list