www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - Are any GUI libs going to make use of signals/slots?

reply "Craig Black" <cblack ara.com> writes:
Is anybody using or planning to use the new signal/slot feature?  Seems like
a powerful feature to me.  I'm curious as to its percieved utility to GUI
library maintainers.

-Craig 
Dec 05 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Tue, 05 Dec 2006 12:38:37 -0500, Craig Black <cblack ara.com> wrote:

 Is anybody using or planning to use the new signal/slot feature?  Seem=

 like
 a powerful feature to me.  I'm curious as to its percieved utility to =

 library maintainers.

 -Craig

DFL has had something like it all along; just use D's ~=3D cat-assign = operator to attach as many event handlers (delegates) as you want. The thing is though, that I don't think I want to use std.signals becaus= e = I actually like that, with DFL's events, an object won't be destructed b= y = the GC if one of the object's member functions is added as an event = handler. For example, take a timer: I have an object and want one of its members = = called back every second, so I add it to a timer's event; I don't want m= y = object destructed just because I'm not referencing it anymore, I still = have the timer setup and want to rely on it to keep on ticking with my = live object. If the timer were to stop and be destructed, then yes, all bets are off = = and my object can be destructed. - Chris
Dec 05 2006
parent reply "Craig Black" <cblack ara.com> writes:
So you are satisfied with the functionality you have with your current 
design.  OK.  As far as the example that you cited, this seems to be a 
specific case.  In this case, would it not be a simple matter to maintain a 
reference to the object that you don't want to be deallocated?

-Craig

"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.tj3ns3mxpo9bzi tanu...
On Tue, 05 Dec 2006 12:38:37 -0500, Craig Black <cblack ara.com> wrote:

 Is anybody using or planning to use the new signal/slot feature?  Seems 
 like
 a powerful feature to me.  I'm curious as to its percieved utility to GUI
 library maintainers.

 -Craig

DFL has had something like it all along; just use D's ~= cat-assign operator to attach as many event handlers (delegates) as you want. The thing is though, that I don't think I want to use std.signals because I actually like that, with DFL's events, an object won't be destructed by the GC if one of the object's member functions is added as an event handler. For example, take a timer: I have an object and want one of its members called back every second, so I add it to a timer's event; I don't want my object destructed just because I'm not referencing it anymore, I still have the timer setup and want to rely on it to keep on ticking with my live object. If the timer were to stop and be destructed, then yes, all bets are off and my object can be destructed. - Chris
Dec 05 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack ara.com> wrote:

 So you are satisfied with the functionality you have with your current
 design.  OK.  As far as the example that you cited, this seems to be a
 specific case.  In this case, would it not be a simple matter to  
 maintain a
 reference to the object that you don't want to be deallocated?

But I told the timer to by registering a callback.. *shrug* I guess if majority of people prefer std.signals I'd switch; I might put up a poll on the DFL forum.
Dec 06 2006
parent reply "Craig Black" <cblack ara.com> writes:
"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.tj42pfdcpo9bzi tanu...
 On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack ara.com> wrote:

 So you are satisfied with the functionality you have with your current
 design.  OK.  As far as the example that you cited, this seems to be a
 specific case.  In this case, would it not be a simple matter to 
 maintain a
 reference to the object that you don't want to be deallocated?

But I told the timer to by registering a callback.. *shrug* I guess if majority of people prefer std.signals I'd switch; I might put up a poll on the DFL forum.

I'm not saying you should switch. It's just worth considering, that's all. If you feel that your current design is better, then no problem. However, slots and signals are widely used in C++ without language support. With language support this approach is all the more attractive It would be nice if all GUI libraries written in D used a standard communication mechanism. Perhaps we could even work toward some sort of interoperability. -Craig -Craig
Dec 06 2006
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Craig Black Wrote:

 
 "Chris Miller" <chris dprogramming.com> wrote in message 
 news:op.tj42pfdcpo9bzi tanu...
 On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack ara.com> wrote:

 So you are satisfied with the functionality you have with your current
 design.  OK.  As far as the example that you cited, this seems to be a
 specific case.  In this case, would it not be a simple matter to 
 maintain a
 reference to the object that you don't want to be deallocated?

But I told the timer to by registering a callback.. *shrug* I guess if majority of people prefer std.signals I'd switch; I might put up a poll on the DFL forum.

I'm not saying you should switch. It's just worth considering, that's all. If you feel that your current design is better, then no problem. However, slots and signals are widely used in C++ without language support. With language support this approach is all the more attractive It would be nice if all GUI libraries written in D used a standard communication mechanism. Perhaps we could even work toward some sort of interoperability. -Craig

But isn't the beauty of signals in D that slots are plain delegates that 'just work'. There is already interoperability in this way. Except for acting as a weak reference, signals are the same as arrays of delegates. Or have I missed your point?
Dec 09 2006
parent reply "Craig Black" <cblack ara.com> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message
news:elft0s$1flt$1 digitaldaemon.com...
 Craig Black Wrote:

 "Chris Miller" <chris dprogramming.com> wrote in message
 news:op.tj42pfdcpo9bzi tanu...
 On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack ara.com>



 So you are satisfied with the functionality you have with your




 design.  OK.  As far as the example that you cited, this seems to be




 specific case.  In this case, would it not be a simple matter to
 maintain a
 reference to the object that you don't want to be deallocated?

But I told the timer to by registering a callback.. *shrug* I guess if majority of people prefer std.signals I'd switch; I might



 up a poll on the DFL forum.

I'm not saying you should switch. It's just worth considering, that's


 If you feel that your current design is better, then no problem.

 However, slots and signals are widely used in C++ without language


 With language support this approach is all the more attractive  It would


 nice if all GUI libraries written in D used a standard communication
 mechanism.  Perhaps we could even work toward some sort of


 -Craig

But isn't the beauty of signals in D that slots are plain delegates that

acting as a weak reference, signals are the same as arrays of delegates.
 Or have I missed your point?

It's just frustrating to that there are so many GUI libs for D, but most are not very complete. Walter tried to remedy this by standardizing on DWT, but it didn't seem to work. If GUI libs were interoperable, that is, if a widget from one lib could plug into a widget from another, then all library maintainers could work together and share a common code base. As it is, everybody is doing their own thing. That's not to be critical of their work. They're doing more good than I am. But if everyone used a common approach, perhaps some common abstract classes, then each contributor could contribute to a common GUI library. Anyway, since signals are part of phobos now, it only seems logical that this could be a common standard. -Craig
Dec 09 2006
parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Craig Black wrote:

 
 "Lutger" <lutger.blijdestijn gmail.com> wrote in message
 news:elft0s$1flt$1 digitaldaemon.com...
 Craig Black Wrote:
 
 
 "Chris Miller" <chris dprogramming.com> wrote in message
 news:op.tj42pfdcpo9bzi tanu...
 On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack ara.com>



 
 So you are satisfied with the functionality you have with your




 design.  OK.  As far as the example that you cited, this seems




 specific case.  In this case, would it not be a simple matter


 reference to the object that you don't want to be deallocated?
 

But I told the timer to by registering a callback.. shrug I guess if majority of people prefer std.signals I'd switch; I might



 up a poll on the DFL forum.

I'm not saying you should switch. It's just worth considering, that's


 If you feel that your current design is better, then no problem.
 
 However, slots and signals are widely used in C++ without language


 With language support this approach is all the more attractive
 It would


 nice if all GUI libraries written in D used a standard
 communication mechanism.  Perhaps we could even work toward some
 sort of


 
 -Craig
 

But isn't the beauty of signals in D that slots are plain delegates that

acting as a weak reference, signals are the same as arrays of delegates.
 Or have I missed your point?

It's just frustrating to that there are so many GUI libs for D, but most are not very complete. Walter tried to remedy this by standardizing on DWT, but it didn't seem to work. If GUI libs were interoperable, that is, if a widget from one lib could plug into a widget from another, then all library maintainers could work together and share a common code base. As it is, everybody is doing their own thing. That's not to be critical of their work. They're doing more good than I am. But if everyone used a common approach, perhaps some common abstract classes, then each contributor could contribute to a common GUI library. Anyway, since signals are part of phobos now, it only seems logical that this could be a common standard. -Craig

While a noble idea, I dont think this is realistic. People want different things from a GUI library and others just like implementing them... I find it highly unlikely that you could make it work due to very different designs...
Dec 10 2006
next sibling parent "Craig Black" <cblack ara.com> writes:
 While a noble idea, I dont think this is realistic. People want
 different things from a GUI library and others just like implementing
 them... I find it highly unlikely that you could make it work due to
 very different designs...

I agree it would be hard. But just because it would be hard doesn't mean we shouldn't try. Perhaps it could be a long term goal. Baby steps can add up over time. -Craig
Dec 10 2006
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:
 Craig Black wrote:
 
 "Lutger" <lutger.blijdestijn gmail.com> wrote in message
 news:elft0s$1flt$1 digitaldaemon.com...
 Craig Black Wrote:

 "Chris Miller" <chris dprogramming.com> wrote in message
 news:op.tj42pfdcpo9bzi tanu...
 On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack ara.com>



 So you are satisfied with the functionality you have with your




 design.  OK.  As far as the example that you cited, this seems




 specific case.  In this case, would it not be a simple matter


 reference to the object that you don't want to be deallocated?

I guess if majority of people prefer std.signals I'd switch; I might



 up a poll on the DFL forum.

that's


 If you feel that your current design is better, then no problem.

 However, slots and signals are widely used in C++ without language


 With language support this approach is all the more attractive
 It would


 nice if all GUI libraries written in D used a standard
 communication mechanism.  Perhaps we could even work toward some
 sort of


 -Craig

that

acting as a weak reference, signals are the same as arrays of delegates.
 Or have I missed your point?

most are not very complete. Walter tried to remedy this by standardizing on DWT, but it didn't seem to work. If GUI libs were interoperable, that is, if a widget from one lib could plug into a widget from another, then all library maintainers could work together and share a common code base. As it is, everybody is doing their own thing. That's not to be critical of their work. They're doing more good than I am. But if everyone used a common approach, perhaps some common abstract classes, then each contributor could contribute to a common GUI library. Anyway, since signals are part of phobos now, it only seems logical that this could be a common standard. -Craig

While a noble idea, I dont think this is realistic. People want different things from a GUI library and others just like implementing them... I find it highly unlikely that you could make it work due to very different designs...

I'm using Phobos signals in my Luigi library (http://www.dsource.org/projects/luigi). However, I felt the need to wrap them because of the limitations of std.signals.Signal. It can only call things with void return type and can only call a slot whose parameter types match exactly. It can also only connect to Object-derived entities. I agree that the "one gui to rule them all" idea doesn't work in practice. Some people want a few lightweight widgets. Some people want basically a full-featured portable OS. Some people want something skinnable. Some people want something that uses native widgets. Some people want a unified look with maximal portability. Some people want a GUI to be drawn on top of their 3D OpenGL app. There's several different axes going on there. It may be theoretically possible to have one toolkit that can satisfy all those needs competing needs, but in the end I think the engineering effort to get it all working would be combinatoric rather than simply additive. I.e if it takes X effort to get something like SWT (wrappers for native widgets) working and Y effort to get FLTK working (light-weight, emulated widgets), then a combined library that neatly unifies the two approaches takes more like X*Y effort than X+Y. Given that, it makes more sense for SWT and FLTK to remain separate. --bb
Dec 22 2006
parent "Craig Black" <cblack ara.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:emel1l$25eu$1 digitaldaemon.com...
 Tomas Lindquist Olsen wrote:
 Craig Black wrote:

 "Lutger" <lutger.blijdestijn gmail.com> wrote in message
 news:elft0s$1flt$1 digitaldaemon.com...
 Craig Black Wrote:

 "Chris Miller" <chris dprogramming.com> wrote in message
 news:op.tj42pfdcpo9bzi tanu...
 On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack ara.com>



 So you are satisfied with the functionality you have with your




 design.  OK.  As far as the example that you cited, this seems




 specific case.  In this case, would it not be a simple matter


 reference to the object that you don't want to be deallocated?

I guess if majority of people prefer std.signals I'd switch; I might



 up a poll on the DFL forum.

that's


 If you feel that your current design is better, then no problem.

 However, slots and signals are widely used in C++ without language


 With language support this approach is all the more attractive
 It would


 nice if all GUI libraries written in D used a standard
 communication mechanism.  Perhaps we could even work toward some
 sort of


 -Craig

that

acting as a weak reference, signals are the same as arrays of delegates.
 Or have I missed your point?

most are not very complete. Walter tried to remedy this by standardizing on DWT, but it didn't seem to work. If GUI libs were interoperable, that is, if a widget from one lib could plug into a widget from another, then all library maintainers could work together and share a common code base. As it is, everybody is doing their own thing. That's not to be critical of their work. They're doing more good than I am. But if everyone used a common approach, perhaps some common abstract classes, then each contributor could contribute to a common GUI library. Anyway, since signals are part of phobos now, it only seems logical that this could be a common standard. -Craig

While a noble idea, I dont think this is realistic. People want different things from a GUI library and others just like implementing them... I find it highly unlikely that you could make it work due to very different designs...

I'm using Phobos signals in my Luigi library (http://www.dsource.org/projects/luigi). However, I felt the need to wrap them because of the limitations of std.signals.Signal. It can only call things with void return type and can only call a slot whose parameter types match exactly. It can also only connect to Object-derived entities. I agree that the "one gui to rule them all" idea doesn't work in practice. Some people want a few lightweight widgets. Some people want basically a full-featured portable OS. Some people want something skinnable. Some people want something that uses native widgets. Some people want a unified look with maximal portability. Some people want a GUI to be drawn on top of their 3D OpenGL app. There's several different axes going on there. It may be theoretically possible to have one toolkit that can satisfy all those needs competing needs, but in the end I think the engineering effort to get it all working would be combinatoric rather than simply additive. I.e if it takes X effort to get something like SWT (wrappers for native widgets) working and Y effort to get FLTK working (light-weight, emulated widgets), then a combined library that neatly unifies the two approaches takes more like X*Y effort than X+Y. Given that, it makes more sense for SWT and FLTK to remain separate. --bb

In this case I would have to disagree. Yes, people want different things in a GUI. Especially experienced developers. And it would be nice if we could have X and Y. But what we end up with is neither being acceptably usable or gaining sufficient momentum. The reality of the matter is that neither X nor Y is maturing quickly enough. Perhaps it would be better to focus on X or Y for the time being until one of them is usable enough to satisfy the basic needs of most GUI developers. Then we can turn our attention to developers with special needs. -Craig
Dec 27 2006
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Craig Black wrote:
 Is anybody using or planning to use the new signal/slot feature?  Seems like
 a powerful feature to me.  I'm curious as to its percieved utility to GUI
 library maintainers.
 
 -Craig 
 

I made a simple OpenGL based GUI for my little library that uses signal/slots (note I just recently completed it but haven't used it for any apps yet, except for test apps). It makes it really easy for users to hook up their own custom code to handle things such as buttons being clicked. One thing I'm curious about is the efficiency of signals and slots. I'm guessing it has slightly more overhead than a normal function call, therefore it is not something to be calling constantly. ~ Clay
Dec 05 2006
next sibling parent "Craig Black" <cblack ara.com> writes:
"clayasaurus" <clayasaurus gmail.com> wrote in message 
news:el4evq$1nbu$1 digitaldaemon.com...
 Craig Black wrote:
 Is anybody using or planning to use the new signal/slot feature?  Seems 
 like
 a powerful feature to me.  I'm curious as to its percieved utility to GUI
 library maintainers.

 -Craig

I made a simple OpenGL based GUI for my little library that uses signal/slots (note I just recently completed it but haven't used it for any apps yet, except for test apps). It makes it really easy for users to hook up their own custom code to handle things such as buttons being clicked. One thing I'm curious about is the efficiency of signals and slots. I'm guessing it has slightly more overhead than a normal function call, therefore it is not something to be calling constantly. ~ Clay

As far as performance, I'm sure it's not that bad. It may be a little less efficient than a regular function call, but since it's primarily used for GUI-related stuff, this small overhead is trivial. However, if you are concerned, you could do a benchmark. Put a call to a signal inside a for loop that iterates a bunch of times, and time it. Test it against a regular delegate invokation, and then a function call. It would be interesting to see the results. -Craig
Dec 05 2006
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
clayasaurus Wrote:

 Craig Black wrote:
 Is anybody using or planning to use the new signal/slot feature?  Seems like
 a powerful feature to me.  I'm curious as to its percieved utility to GUI
 library maintainers.
 
 -Craig 
 

I made a simple OpenGL based GUI for my little library that uses signal/slots (note I just recently completed it but haven't used it for any apps yet, except for test apps). It makes it really easy for users to hook up their own custom code to handle things such as buttons being clicked. One thing I'm curious about is the efficiency of signals and slots. I'm guessing it has slightly more overhead than a normal function call, therefore it is not something to be calling constantly. ~ Clay

Only way to be sure is to profile, but performance cost should be very small. It is implemented like this, slot is the delegate: foreach (slot; slots[0 .. slots_idx]) if (slot) slot(i); I think usage of signals will only matter if your code would benefit a lot from being inlined, but better not to do assumptions.
Dec 09 2006