Re: Theory of good signal/event API design?

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 2007-09-25 at 09:07 +0200, Sander Marechal wrote:
> Andy Wingo wrote:
> > You probably won't get terribly useful answers here, GStreamer's bus is
> > not present in other GObject-based libraries like GTK+. Even if it were,
> > this is probably more appropriate to gtk-app-devel.
> > 
> > Consider writing to gstreamer-devel.
> 
> I wrote there too, but got no comments. The reason I posted to the GTK
> lists as well is because GTK is also event/signal driven. I'm not
> looking for anything GStreamer (or other technology) specific, but for
> general information about event driven programming.

Well, it's event driven, but its all done in the main event loop.  It's
not really like a message bus system of the kind that I think you are
interested in.  If you want to add additional events to the main loop
you can use g_idle_add() (which also happens to be thread safe, so you
can use it to pass events from worker threads to the main GUI thread).

GSignal objects are in effect just lists of closures/callbacks, and are
a C wrapper to provide a relatively type safe way of executing arbitrary
callbacks with arbitrary data, and not dissimilar to C++ libraries such
as libsigc++ and boost::signal.  I suspect they are used in GTK+
whenever it is thought a library user might want to do something, were
the particular event (such as an X event or user interaction with a GUI
element) to occur.  GSignal objects do not have anything particular to
do with message busses.

If you want a message bus, these days most people would I think use a
session (as opposed to system) message bus using dbus.

Chris