On Thu, Jan 15, 2009 at 9:18 AM, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> Bill Baxter wrote:
> <snip>
>>
>> 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.
>
> <snip>
>
> Qt isn't a GUI toolkit - it's a multi-purpose library that happens to have a GUI toolkit among its components.

I'd write that:
Qt isn't just a GUI toolkit - it's a multi-purpose library that also
happens to have a great GUI toolkit.

But ok.
Qt's GUI toolkit is the best damn GUI toolkit there is.  Does that
read better to you?

--bb

It was GPL or commercial before.

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

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

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.

On 1/16/2009 12:50 AM, Nick Sabalausky wrote:
>
>  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.
>

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.

-- serg

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.

On Fri, Jan 16, 2009 at 8:26 AM, BLS <windevguy@hotmail.de> 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

They are a bit different.  In Phobos and Tango those are compile-time
signals and slots.
Meaning that all the signatures have to be known at compile time.

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

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.

Compare these two classes: http://doc.trolltech.com/4.3/qimage.html http://docs.wxwidgets.org/2.8/wx_wximage.html

First off the formatting of the wx doc just makes my head hurt.  But we'll ignore that.  Look at things like QImage::createHeuristicMask vs wxImage::GetOrFindMaskColour().   Both functions have to do with making a mask when you don't know what the mask color should be.  But the Qt doc actually describes how it does what it does, the wx doc basically just repeats the name of the function.  And the name of the Qt function is just nicer.  And it gives you back something which you might have a use for (a mask image) as opposed to the wx version which just gives you the color that you have to use to go create a mask yourself.  When are you going to need just the color?   The Qt API is like that all over.  Almost always it has a nicely named function that does just what you need instead of several not-so-nicely named ones that you have to combine to get the result you want.

Also check this out: http://doc.trolltech.com/4.3/qscrollbar

You can get to the doc for any class just with that.  Just stick the name of the class you want doc for at the end of doc.trolltech.com/{version}/  and it will tell you where the thing you want is.

Wx have done a pretty good job copying the Qt doc setup, but they just
didn't quite get the details as nice.  To get the doc you have to type
exactly this:
http://docs.wxwidgets.org/2.6/wx_wxscrollbar.html
Extra 's' in the url, extra 'wx_' in the names, and '.html' cannot be omitted.

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.

--bb

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.

--bb

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.