[QOF-devel] Outline of new qofevent support

[Derek Atkins]

Chris Shoemaker <c.shoemaker at cox.net> writes:

> 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.

My personal feeling is that changing to gobject is not a libqof-1
change.  I wholeheartedly agree it should be done, but not today.
Let's get gnucash-2.0 and qof-0.7 released and then we can go rototill
and use gobject.

While it might appear to be possible to make incremental changes, I
think that might be a lot more work than just going through and doing
it all at once.  For example, my "subject-verb-object" could be
handled by a g_signal thrown against the subject, with the object as a
signal argument...  But we still need to think abot how to handle
"global" signals, signals that technically have no subject.

I don't think these changes should be made lightly or hurriedly, so I'd
like to suggest we wait..

I'll point out that adding a few new APIs for short-term use is very
different than changing the structure of the library.

> -chris

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available