Beyond 2.6

[David Carlson]

On 2/9/2013 11:49 AM, Geert Janssens wrote:
> On 09-02-13 00:12, David Carlson wrote:
>> 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
>>
>>
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> What exactly do you mean by this ?
>
> Geert
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
I am not sure about details, but I thought that there was a long term
goal to use a database engine and file structure as a way to get to
supporting multiuser functionality.  Driving a database engine would
require radically different (and sometimes simpler) code than doing it
all hard-coded.  I thought that might influence other decisions. 
However I am not a developer, so I am trying to avoid any specific
suggestion about how to do the coding.

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/20130209/4030e67b/attachment.bin>