[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 --