On Tue, Feb 21, 2006 at 10:15:31AM +0100, Christian Stimming wrote: > Derek Atkins schrieb: > >I'd propose: > > (...) > > > >I admit this would be a LOT easier if QOF were based on gobject and we > >used g_signal... Mea Culpa. > > > >What do you think? > > Actually that was what I was thinking. *Iff* the API should be changed > anyway, and as QOF depends on glib deeply anyway, what are the reasons > for not making the transition of QOF to be based on gobject and g_signal? >
BTW and FTR, I am in very strong favor of this idea, especially the reasoning "if we're changing the API _anyway_". Also, I believe that, with some care, this transition can be done incrementally. For example, the conversion to gobject-based qofobject doesn't have to impact a whole lot of other stuff. The g_signals can be introduced one-at-a-time and can exist along-side the existing event mechanism. They can even be stubbed into the existing event mechanism so that event consumers don't even notice the difference even when the base objects are actually triggering event generation with g_signals. I'll also note that g_signal is perhaps the most obvious benefit of a move toward gobject, but it's certainly not the only one. There's also the type-system which we're presently trying to fake, and several other features that are functionally equivalent to our own code. I think the most important technical point here is that its not "all or nothing." A switch to gobject is compatible with everything we're currently doing, so we could transition gradually to gobject-provided functionality. -chris _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
