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

[Bill Baxter]

Tomas Lindquist Olsen wrote:
> Craig Black wrote:
> 
>> "Lutger" <lutger.blijdestijn at gmail.com> wrote in message
>> news:elft0s$1flt$1 at digitaldaemon.com...
>>> Craig Black Wrote:
>>>
>>>> "Chris Miller" <chris at dprogramming.com> wrote in message
>>>> news:op.tj42pfdcpo9bzi at tanu...
>>>>> On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack at 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?
>> 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 
(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