On Tue, Feb 21, 2006 at 01:42:33PM -0500, Derek Atkins wrote: > Quoting David Hampton <[EMAIL PROTECTED]>: > > >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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
