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
