Are any GUI libs going to make use of signals/slots?

Craig Black cblack at
Wed Dec 27 07:58:52 PST 2006

"Bill Baxter" <dnewsgroup at> wrote in message 
news:emel1l$25eu$1 at
> Tomas Lindquist Olsen wrote:
>> Craig Black wrote:
>>> "Lutger" <lutger.blijdestijn at> wrote in message
>>> news:elft0s$1flt$1 at
>>>> Craig Black Wrote:
>>>>> "Chris Miller" <chris at> wrote in message
>>>>> news:op.tj42pfdcpo9bzi at tanu...
>>>>>> On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack at>
>>> 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?
>>> 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...
> I'm using Phobos signals in my Luigi library 
> (
> 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.


More information about the Digitalmars-d-dwt mailing list