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