On Feb 8, 2013, at 8:01 PM, John Ralls <jra...@ceridwen.us> wrote: > > On Feb 8, 2013, at 1:03 PM, Christian Stimming <christ...@cstimming.de> 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. > > I thought that you'd found more gainful employ. ;-) Hope it's working out > well for you. > > Agreed, we will at some point have to deal with signals, but there's plenty > of engine and backend stuff that > can be reimplemented before that. There are also a Boost signals/slots > libraries. My main near-term interest > is in replacing the rather arcane and verbose GObject typing, construction, > destruction, and reference > counting with the easier to write and more readable C++ equivalents. > > As for Gtkmm, it's just a C++ interface wrapped around Gtk+. If we're dumping > Gtk+ because we don't > like the direction they're going, Gtkmm doesn't get us anywhere.
Having argued that C++ in the backend in not such a big deal, I'm going to turn around and point out that dropping Gtk+ in favor of wx, Qt, or some other GUI framework isn't a easy job: That *is* a complete rewrite, and there's a lot of it. Who would do it? Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
