[haiku-development] Signals and Slots

  • From: Pete Goodeve <pete.goodeve@xxxxxxxxxxxx>
  • To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
  • Date: Tue, 28 Feb 2012 13:56:59 -0800

[I've pulled this out of the R1/A4 thread because it's wandered pretty
far OT, but I thought it worth one more note]

It looks as if we could get pretty adequate "Signals and Slots" in Haiku
with no changes to any kits and essentially no effort.  I've been playing
some more with sigslot.h ( http://sigslot.sourceforge.net/ ) and it's looking
pretty capable.  I suggest that anyone interested in the paradigm should
check it out.  We could even put it in the distribution, as it's nothing but
a 5K public domain header!

I thought initially that it might not be a solid implementation of the
concept -- would it handle the deletion of an object with a connected
slot, for instance?  It turns out it does so nicely.  I can create a window
with a slot, for instance, connect to it, see the signals arriving, then
Quit the window.  The connection is cleanly broken, and the program
goes happily on.  Everything seems well protected with mutexes, so
it should be solid.

And there's no real downside to slots being executed in the calling thread.
Just like I often do with a BWindow or other looper, you just put a Lock
around any critical section.

Alternatively, I could just use a BMessage as the signal data and connect it
to a single slot in the looper that simply posts the message to itself.
Then it's handled in MessageReceived as usual.  It's not the Qt way
of having a slot for each kind of signal, but "it's the Haiku Way"... (:-)

You might think this is just a roundabout way of doing the usual
PostMessage to a looper, but the big difference is that there is no
fixed link between the signaller and the receiver (or receivers).
You can set up the message and send it out without worrying 
exactly who is going to do anything with it.  And connections are
dynamic -- make or break them at any time.

To reiterate, I don't see any need for signals and slots to replace
BMessages for most uses, but I can envisage places where their
dynamic, many-tomany, connections could be useful.  I have at
least one possible use in my own code.

        -- Pete --

Other related posts: