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>
> 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...

> 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

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>
>> 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

"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>
>>> 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

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