[haiku-development] Re: R1/a4 initial planning

On Mon, Feb 27, 2012 at 09:48:12AM +0100, fano il primo wrote:
> On Sun, Feb 26, 2012 at 11:25 PM, Pete Goodeve 
> <pete.goodeve@xxxxxxxxxxxx>wrote:
> > Just fTR, while trying to learn something about Qt myself (never used it),
> > I came across the "sigslot library": http://sigslot.sourceforge.net/

> >                 It's not quite the same as the Qt concept, because there's
> > no inter-thread invocation of slots -- they're always executed in the
> > calling thread -- but it might be interesting to take a look at.
> >
> > As this shows, a moc isn't necessary for the concept itself, and I can't
> > see any fundamental reason why behind-the-scenes queueing couldn't
> > be added (though it would need more than a header).
> >
 > I think Haiku API "MessageReceived()" method is more simple to
> understood/use that the Slot/Signal method... moc or not, I'd say is more
> clear that for a button pressed I receive a Message from it, that I do have
> to "connect" to be notified... more "C" like approach maybe, instead the Qt
> is more C++ like, maybe, as all is hidden to the user/developer: if you see
> the "moc" code wed see a classic loop and a switch... in the end the same
> thing of MessageReceived(), right?

To clarify, I was *not* suggesting signals/slots as a replacement for
BMessages.  However, I thought if they could be implemented on top
of our current scheme they might be a useful feature to have on
occasion.

The (possibly) nice property of signals/slots is that they are 'many-to-many',
as opposed to the single sender/receiver in messages.  I'm pretty satisfied
with setting up messages with targets, but I can conceive of situations
where adding and removing slots might be convenient.

I haven't thought deeply about implementation at all, but I'd imagine
sending a signal would create a specially configured BMessage for each
(queueable) slot, containing a pointer to the slot method and the data,
and the BLooper would know about such messages and dispatch them
appropriately.  (For experimental development one wouldn't need a modified
BLooper -- just a customized MessageReceived.)  The implementation would have 
to be able to handle a slot being deleted after being connected, but 
I think BMessengers would work for that. 

> 
> Maybe it could be better in some cases a callback mechanism?
> Let suppose this new BButton constructor:
> 
>                btn = new BButton(BRect(10, 10, 60, 30), "Test", "TEST",
>                                           beApp->clicked));
> 

I don't see this giving any advantage over a message.  It's still
one-to-one, anyway.

> 
> What do you think?
> In the end the slot/signal is if you want to not use more MessageReceived,
> correct?

As I said, I see it as possibly complementary -- not a replacement.

Cheers,
        -- Pete --

Other related posts: