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 > [email protected] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > Also please keep in mind your goals regarding database filetypes.
David C
0xDC7C8BF3.asc
Description: application/pgp-keys
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
