On Fri, Jan 16, 2009 at 10:22 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> On Fri, Jan 16, 2009 at 9:00 AM, Yigal Chripun <yigal100@gmail.com> wrote:
>>
>>> 2. there's more to S&S than just an array of delegates - they are weak
>>> refs
>>> so that destruction of an object disconnects automatically the apropriate
>>> signals. but there is a weakref lib for D written by Bill IIRC, that
>>> could
>>> be utilized in qtD. no pre-processor needed.
>>
>> The "delegates" in Qt are more like a QObject,QString pair.  The object and the *name* of the method to call.
>>
>> And there aren't really "weak refs" in Qt.  When you connect a signal and slot it also makes some extra connections between the two objects' destroyed() signals.  So each object is also listening for the other object to be destroyed.   Sort of a weak ref, but more like a strong ref with active notifications about destruction either way.   In a GC'ed language with real weak refs, the slot holder doesn't have to worry if the signal sender disappears.
>
> This is taken care of in std.signals.

WeakRef Yigal was referring to is just a handy wrapper class for the same GC callback that std.signals uses.  Plus it's compatible with both Phobos and Tango.

--bb

Bill Baxter Wrote:
> In Qt the binding is more dynamic.  You can call a slot in Qt even if
> all you have is its name in a run-time string.
> Qt also uses a similar mechanism to provide runtime dynamic
> properties.  For anything derived from QObject you can ask if it has a
> "color" property (again using a string), for instance.   Given enough
> reflection capabilities, D could potentially turn compile time info
> into similar run-time queryable strings, so I'm guessing that's why
> they said they might not need MOC if D's reflection proves sufficient.
>  Qt may also be able to add a

This is exactly correct. Even D2 currently lacks the introspection capabilities provided by moc. In addition to providing the code for signals/solts moc also provides for things like getting a list of enums in a class, converting enum values to and from string (technically moc doesn't do this conversion, it just makes it possible), a string list of object properties and their types, you can even add new signals and slots dynamically at run time (which may not even be members of the class that you are declaring them to be a slot of). Qt's signal/slot implementation is also thread safe (connecting a signal from one thread to a slot in another I mean), and provides several options for how a slot actually gets called by a signal (directly, via the event loop, etc). This level of "dynamic-ness" is what makes bindings to Qt possible in the first place.

People often forget, though, that Qt actually has 2 programs which typically run before compilation, moc and uic. uic is responsible for converting the XML files generated by Qt Designer into C++. Even if you do away with running moc first, you still need to run uic.

I would love if we could not need moc, but unless D2's introspection improves a lot before QtD is ready it will probably be a neccesity and there is no good way around using uic. Sure you can load and process the xml files at runtime, but there is of course a real performance cost to that compared with compiling in standard code.

> But really signals and slots is just an interesting implementation detail about Qt.  What makes it great to me is just the completeness of it and the amount of thought which has gone into making a clean, clear and consistent API.   The docs are also great.

I totally agree, having a single, consistent framework for everything from TCP connections to rendering advanced 2d graphics scenes to embeding OpenGL and shared memory handling (plus a lot more of course) makes it hands down one of the best toolkits available. Not only is its API clean, clear, and consistent, its internal implementation generally shares these qualities.

> It's kinda like that all over.  Tons of small things everywhere in Qt that just make you go, "Oh that's really nice".  You can write real applications just fine using either wx or Qt, but very seldom do I have those "oh wow" moments using wx.

I have been using Qt for years now, and I still have those "oh wow" moments.

P.S.
You may have guessed this already, but I'm one of the developers working on QtD ;-)

---
Katrina

Bill Baxter wrote:
> On Fri, Jan 16, 2009 at 10:22 AM, Walter Bright
> <newshound1@digitalmars.com>  wrote:
>> Bill Baxter wrote:
>>> On Fri, Jan 16, 2009 at 9:00 AM, Yigal Chripun<yigal100@gmail.com>  wrote:
>>>
>>>> 2. there's more to S&S than just an array of delegates - they are weak
>>>> refs
>>>> so that destruction of an object disconnects automatically the apropriate
>>>> signals. but there is a weakref lib for D written by Bill IIRC, that
>>>> could
>>>> be utilized in qtD. no pre-processor needed.
>>> The "delegates" in Qt are more like a QObject,QString pair.  The
>>> object and the *name* of the method to call.
>>>
>>> And there aren't really "weak refs" in Qt.  When you connect a signal
>>> and slot it also makes some extra connections between the two objects'
>>> destroyed() signals.  So each object is also listening for the other
>>> object to be destroyed.   Sort of a weak ref, but more like a strong
>>> ref with active notifications about destruction either way.   In a
>>> GC'ed language with real weak refs, the slot holder doesn't have to
>>> worry if the signal sender disappears.
>> This is taken care of in std.signals.
>
> WeakRef Yigal was referring to is just a handy wrapper class for the
> same GC callback that std.signals uses.  Plus it's compatible with
> both Phobos and Tango.
>
> --bb

What I meant was that QT provides the functionality of a weakref, but you're right that that's not a "real" weak ref.
still, I think this functionality need to be implemented in qtD and luckily D does have true weakrefs that can be utilized for this.

Question: since D2 now uses the same runtime as tango and that includes the (same) GC, do we still need the wrapper, for D2 code?

On Fri, Jan 16, 2009 at 12:52 AM, Sergey Kovrov <kovrov+digitalmars@gmail.com> wrote:
> Well, from what I've read and observe now, Qt just mimics native look (but not really feel). In fact since relaese of 4.4 it uses "windowless UI" by default.

I use Qt daily, and it uses native widgets in recent versions. Of course, with the exception of X11, because there is no such thing as native widgets (arguably, Qt is one of the major two native toolkits for X11). E.g. in OS X Qt uses Carbon (or Cocoa from 4.5 on).

On 1/16/2009 10:34 AM, Daniel de Kok wrote:
> I use Qt daily, and it uses native widgets in recent versions. Of
> course, with the exception of X11, because there is no such thing as
> native widgets (arguably, Qt is one of the major two native toolkits
> for X11). E.g. in OS X Qt uses Carbon (or Cocoa from 4.5 on).

Maybe there is some misunderstanding. By the "native widgets" I mean Windows Common Controls - buttons, combo boxes, status bars, etc.

This is the note from a Qt developer I was referring to http://labs.trolltech.com/blogs/2007/08/30/say-goodbye-to-flicker-aliens-are-here-to-stay/

And right now I can see (using spy++) I that Qt (4.4.3) applications are using only one native window handle per top level window. There are few more hidden window probably used for worker threads and reserved for stuff like tooltips etc...

That makes me think Qt might be using GDI (DrawEdge, DrawFocusRect, etc.) or Themes API to draw widgets that looks native. But surely they use their own "widget logic".

-- serg.

On Fri, Jan 16, 2009 at 7:42 PM, Sergey Kovrov <kovrov+digitalmars@gmail.com> wrote:
> On 1/16/2009 10:34 AM, Daniel de Kok wrote:
>>
>> I use Qt daily, and it uses native widgets in recent versions. Of course, with the exception of X11, because there is no such thing as native widgets (arguably, Qt is one of the major two native toolkits for X11). E.g. in OS X Qt uses Carbon (or Cocoa from 4.5 on).
>
> Maybe there is some misunderstanding. By the "native widgets" I mean Windows Common Controls - buttons, combo boxes, status bars, etc.
>
> This is the note from a Qt developer I was referring to http://labs.trolltech.com/blogs/2007/08/30/say-goodbye-to-flicker-aliens-are-here-to-stay/
>
> And right now I can see (using spy++) I that Qt (4.4.3) applications are using only one native window handle per top level window. There are few more hidden window probably used for worker threads and reserved for stuff like tooltips etc...
>
> That makes me think Qt might be using GDI (DrawEdge, DrawFocusRect, etc.) or Themes API to draw widgets that looks native. But surely they use their own "widget logic".

Maybe the confusion is over the switch to native dialogs for things like file selection and printing?  The first few versions of Qt used their own dialogs for that, but they switched to using native dialogs at some point.

--bb

Yigal Chripun Wrote:

> Bill Baxter wrote:
> > On Fri, Jan 16, 2009 at 10:22 AM, Walter Bright <newshound1@digitalmars.com>  wrote:
> >> Bill Baxter wrote:
> >>> On Fri, Jan 16, 2009 at 9:00 AM, Yigal Chripun<yigal100@gmail.com>  wrote:
> >>>
> >>>> 2. there's more to S&S than just an array of delegates - they are weak
> >>>> refs
> >>>> so that destruction of an object disconnects automatically the apropriate
> >>>> signals. but there is a weakref lib for D written by Bill IIRC, that
> >>>> could
> >>>> be utilized in qtD. no pre-processor needed.
> >>> The "delegates" in Qt are more like a QObject,QString pair.  The object and the *name* of the method to call.
> >>>
> >>> And there aren't really "weak refs" in Qt.  When you connect a signal and slot it also makes some extra connections between the two objects' destroyed() signals.  So each object is also listening for the other object to be destroyed.   Sort of a weak ref, but more like a strong ref with active notifications about destruction either way.   In a GC'ed language with real weak refs, the slot holder doesn't have to worry if the signal sender disappears.
> >> This is taken care of in std.signals.
> >
> > WeakRef Yigal was referring to is just a handy wrapper class for the same GC callback that std.signals uses.  Plus it's compatible with both Phobos and Tango.
> >
> > --bb
> 
> What I meant was that QT provides the functionality of a weakref, but
> you're right that that's not a "real" weak ref.
> still, I think this functionality need to be implemented in qtD and
> luckily D does have true weakrefs that can be utilized for this.
> 
> Question: since D2 now uses the same runtime as tango and that includes the (same) GC, do we still need the wrapper, for D2 code?

What do you mean by wrapper? Or you mean extern C++ capabilites of D2? I tried them, and they seem really poor. Besides nobody who I was asking knows when D2 finally stabilise and goes out of beta, tango for example isn't going to be ported to D2 in nearest future.

Eldar Insafutdinov wrote:
> Yigal Chripun Wrote:
>
>> Bill Baxter wrote:
>>> On Fri, Jan 16, 2009 at 10:22 AM, Walter Bright
>>> <newshound1@digitalmars.com>   wrote:
>>>> Bill Baxter wrote:
>>>>> On Fri, Jan 16, 2009 at 9:00 AM, Yigal
>>>>> Chripun<yigal100@gmail.com>   wrote:
>>>>>
>>>>>> 2. there's more to S&S than just an array of delegates -
>>>>>> they are weak refs so that destruction of an object
>>>>>> disconnects automatically the apropriate signals. but there
>>>>>> is a weakref lib for D written by Bill IIRC, that could be
>>>>>> utilized in qtD. no pre-processor needed.
>>>>> The "delegates" in Qt are more like a QObject,QString pair.
>>>>> The object and the *name* of the method to call.
>>>>>
>>>>> And there aren't really "weak refs" in Qt.  When you connect
>>>>> a signal and slot it also makes some extra connections
>>>>> between the two objects' destroyed() signals.  So each object
>>>>> is also listening for the other object to be destroyed.
>>>>> Sort of a weak ref, but more like a strong ref with active
>>>>> notifications about destruction either way.   In a GC'ed
>>>>> language with real weak refs, the slot holder doesn't have
>>>>> to worry if the signal sender disappears.
>>>> This is taken care of in std.signals.
>>> WeakRef Yigal was referring to is just a handy wrapper class for
>>> the same GC callback that std.signals uses.  Plus it's compatible
>>> with both Phobos and Tango.
>>>
>>> --bb
>> What I meant was that QT provides the functionality of a weakref,
>> but you're right that that's not a "real" weak ref. still, I think
>> this functionality need to be implemented in qtD and luckily D does
>> have true weakrefs that can be utilized for this.
>>
>> Question: since D2 now uses the same runtime as tango and that
>> includes the (same) GC, do we still need the wrapper, for D2 code?
>
> What do you mean by wrapper? Or you mean extern C++ capabilites of
> D2? I tried them, and they seem really poor. Besides nobody who I was
> asking knows when D2 finally stabilise and goes out of beta, tango
> for example isn't going to be ported to D2 in nearest future.

I was refering to Bill's WeakRef class. In the above quote you can see that he said: "WeakRef Yigal was referring to is just a handy wrapper class for the same GC callback that std.signals uses.  Plus it's compatible with both Phobos and Tango."

Yigal Chripun wrote:
> BLS wrote:
>> Nick Sabalausky wrote:
>>> "BLS" <windevguy@hotmail.de> wrote in message
>>> news:gkodf2$1aht$1@digitalmars.com...
>>>> Bill Baxter wrote:
>>>>> On Thu, Jan 15, 2009 at 4:42 AM, naryl <cy@ngs.ru> wrote:
>>>>>> On Wed, 14 Jan 2009 18:40:19 +0300, Bill Baxter <wbaxter@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Qt 4.5 to be LGPL
>>>>>>> http://tech.slashdot.org/article.pl?sid=09%2F01%2F14%2F1312210
>>>>>>>
>>>>>>> Now we just need a D port...
>>>>>>>
>>>>>>> --bb
>>>>>> There is a binding currently in development.
>>>>>> http://code.google.com/p/qtd/
>>>>> Excellent. I didn't know anyone was working on it. Qt is simply the
>>>>> best damn GUI toolkit there is. But I wouldn't touch it with a meter
>>>>> long chopstick when it was GPL.
>>>>>
>>>>> I guess the D port is going to have MOC too?
>>>>>
>>>>> --bb
>>>> I am just curious: Why QT is such a damned cool toolkit ?
>>>> In other words, how is it better than wxWidgets ?
>>>>
>>>> I've never used QT but QT is IMO more comparable to SWING in that it
>>>> mimics native controls/widgets...so semi-optimal.
>>>> ...and what the heck is MOC ?
>>>> Bjoern
>>>>
>>>
>>> From what I gather from having recently been trying to read up on Qt:
>>>
>>> - The newer verions of Qt actually use the real native widgets, unlike
>>> older versions of Qt.
>>>
>>> - MOC is a preprocessor packaged with Qt. Qt uses this concept of
>>> "signals" and "sockets", which are apperently just like using a
>>> delegate collection (ie, like "(void delegate())[]" or C#/WinForm's
>>> event system, or something like that). Problem is, the original
>>> version of Qt is made for C++, which doesn't have proper delegates (at
>>> least not last I checked). So they hacked it together using a special
>>> preprocessor for C++ code.
>>>
>>>
>>
>> Phobos as well as Tango are offering support for signals and
>> slots...does this mean that MOC/D is not not needed for a QtD ? Sorry
>> for my ignorance, but I can't get it.
>> Bjoern
>>
>> PS seems there is an upcoming D-preprocessor project on dsource.
> 
> two notes:
> 1. my personal view - assert(pre-processor is evil)
> 2. there's more to S&S than just an array of delegates - they are weak refs so that destruction of an object disconnects automatically the apropriate signals. but there is a weakref lib for D written by Bill IIRC, that could be utilized in qtD. no pre-processor needed.
> 

The MOC may seem scary but its actually one of the most solid parts of the Qt Library....

Sergey Kovrov wrote:
> On 1/16/2009 10:34 AM, Daniel de Kok wrote:
>> I use Qt daily, and it uses native widgets in recent versions. Of
>> course, with the exception of X11, because there is no such thing as
>> native widgets (arguably, Qt is one of the major two native toolkits
>> for X11). E.g. in OS X Qt uses Carbon (or Cocoa from 4.5 on).
> 
> Maybe there is some misunderstanding. By the "native widgets" I mean Windows Common Controls - buttons, combo boxes, status bars, etc.
> 
> This is the note from a Qt developer I was referring to http://labs.trolltech.com/blogs/2007/08/30/say-goodbye-to-flicker-aliens-are-here-to-stay/ 
> 
> 
> And right now I can see (using spy++) I that Qt (4.4.3) applications are using only one native window handle per top level window. There are few more hidden window probably used for worker threads and reserved for stuff like tooltips etc...
> 
> That makes me think Qt might be using GDI (DrawEdge, DrawFocusRect, etc.) or Themes API to draw widgets that looks native. But surely they use their own "widget logic".
> 
> -- serg.

Yes its a native style thats being applied but the standard QWidgets that make them look and feel 'native'

http://doc.trolltech.com/4.4/qwindowsxpstyle.html
http://doc.trolltech.com/4.4/qwindowsvistastyle.html
http://doc.trolltech.com/4.4/qmacstyle.html