On Sun, Feb 26, 2012 at 11:25 PM, Pete Goodeve <pete.goodeve@xxxxxxxxxxxx>wrote: > On Sun, Feb 26, 2012 at 02:37:08PM -0500, Ryan Leavengood wrote: > > > > I would like to see if it is possible to implement some of the nice > > parts of signals and slots without requiring a special pre-processor > > like moc. Maybe some aspects of C++0x could be used for this, such as > > lambdas. This could be an area where Haiku could innovate because of > > our ability or desire to not worry about backwards compatibility in > > R2. > > Just fTR, while trying to learn something about Qt myself (never used it), > I came across the "sigslot library": http://sigslot.sourceforge.net/ > (She calls it a 'library' but it's actually simply a header file with > lotsnlotsa > templates.) 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 was able to whip up a quickie test program, appended below, that > wored a treat first time [once I'd read the docs properly... (:-/)]. > > Cheers, > -- Pete -- > > ------------------------- > > // Test of sigslot > > #include <Application.h> > #include <Window.h> > #include <Button.h> > #include <Message.h> > > #include "sigslot.h" > using namespace sigslot; > > class SSWindow : public BWindow { > public: > BButton *btn; > SSWindow() : BWindow(BRect(40,40, 140, 80), "Test", > B_TITLED_WINDOW, 0) > { > btn = new BButton(BRect(10, 10, 60, 30), "Test", "TEST", > new BMessage('butn')); > AddChild(btn); > } > signal0<> click; // A signal with no arguments > void MessageReceived(BMessage *msg) { > switch(msg->what) { > case 'butn': > click();// emit the signal > break; > } > } > bool QuitRequested() > { > be_app->PostMessage(B_QUIT_REQUESTED); > return true; > }; > }; > > > class SSApp : public BApplication, public has_slots<> { > public: > SSWindow *w; > SSApp() : BApplication("application/x-test-sigslot") { > w = new SSWindow(); > w->Show(); > w->click.connect(this, &SSApp::clicked); > } > void clicked() { // The "slot" method > printf("button clicked\n"); > } > }; > > main() { > new SSApp(); > be_app->Run(); > delete be_app; > } > > 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? 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)); where "clicked" is a pointer to the function to call where the button is clicked, that is you not receive nothing from this button in MessageReceived() and this function is called for you... it's the same approach of the methods ArgsReceived() and RefsReceived() in the end... What do you think? In the end the slot/signal is if you want to not use more MessageReceived, correct? fano