Chris Shoemaker <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
