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@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@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > What exactly do you mean by this ? > > Geert > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@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
0xDC7C8BF3.asc
Description: application/pgp-keys
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
