[QOF-devel] Outline of new qofevent support

[Chris Shoemaker]

On Tue, Feb 21, 2006 at 01:42:33PM -0500, Derek Atkins wrote:
> Quoting David Hampton <hampton-gnucash at rainbolthampton.net>:
> 
> >On Tue, 2006-02-21 at 12:27 -0500, Derek Atkins wrote:
> >
> >>Except qof is glib-only..  Is GnomeProgram in glib or gobject?
> >>I suspect we could "pass down" a "global" gobject reference into
> >>qof for the 'global' events..
> >
> >Neither.  Its in gnome, but its derived from a GObject so any code
> >linked against the gobject library will suport it.
> 
> Yes, but how does libqof gain access to that?  At that point we might
> as well just have:
> 
>   void qof_event_register_base(GObject*);
> 
> And let the application deal..

I'm not convinced we really need a global signal source because I
don't think we really have global events.  Every event has _some_
context, and, yeah, sometimes it's the session.

[ But anyway, even if there was a global signal source, I wouldn't
expect to be able to "register" it.  I'd expect qof to tell me what it
is.  Maybe:

QofProgram * qof_init(void);
]

> 
> >>I need to think about how that would work.   Or perhaps we can make
> >>global events go to the QofSession?  *ponders*
> >
> >Then you're back to multiple models for events.  That is, unless the
> >session becomes an object derived from GObject.
> 
> Well, I think the point was that every Qof object would derive from
> gobject.  At least that's what I had in mind.  

Same here.

> So, yes, a QofSession would be derived from GObject.  The only
> remaining question is whether we would want cross-session events, or
> if we need an event when we create a new session?

I doubt it.  I can't see QofSessions being created/destroyed
implicitly.  Session management is pretty explicit.

> Again, I think we need to really think hard about how we want events to
> work.  Do we want events passed up the stack?  

One nice thing about the decentralized signal model of gobject is that
you're free to make those decisions on a per-signal basis.  You don't
have to decide on one over-arching event-propagation model.  If you
want one particular signal to cascade into another signal for a
"containing" object, you can make that signal work that way.

> How do we make sure that a signal handler doesn't eat a signal?

Not sure what you mean here, but if you're thinking about the
Scheme-style hash-table iterators, where the closure can abort the
iteration by returning #f or something, then that's a completely
optional feature of GSignal, and not one I've seen much used.

-chris