www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Qt 4.5 to be LGPL

reply Bill Baxter <wbaxter gmail.com> writes:
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
Jan 14 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.400.1231947622.22690.digitalmars-d puremagic.com...

 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


What was it before? (Pardon my ignorance)
Jan 14 2009
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:


 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.400.1231947622.22690.digitalmars-d puremagic.com...

 Qt 4.5 to be LGPL
 http://tech.slashdot.org/article.pl?sid=09%2F01%2F14%2F1312210

 Now we just need a D port...




...and a sponsor to make the port? I wonder how feasible it is to create 
automated bindings. 


 --bb


 
 What was it before? (Pardon my ignorance)


GPL or Expensive, it's in the article.
Jan 14 2009
prev sibling parent rd999 <rubberduck999 gmx.de> writes:
It was GPL or commercial before.
Jan 14 2009
prev sibling next sibling parent J Duncan <jtd514_ ameritech.net> writes:
Bill Baxter 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


http://www.qtsoftware.com/about/news/qt-creator-ide-beta-released
then there is this.....
Jan 14 2009
prev sibling next sibling parent reply naryl <cy ngs.ru> writes:
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/
Jan 14 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
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
Jan 14 2009
next sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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


Hi! We still think about it, we are not really sure if D1 has enough
introspection capabilities to do it without preprocessor. D2 probably has
enough, but we are targeting D1 for well known reasons.
Jan 14 2009
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.

Stewart.
Jan 14 2009
parent Bill Baxter <wbaxter gmail.com> writes:
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
Jan 14 2009
prev sibling parent reply BLS <windevguy hotmail.de> writes:
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
Jan 15 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"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 

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.
Jan 15 2009
next sibling parent reply BLS <windevguy hotmail.de> writes:
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 

 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.
Jan 15 2009
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
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

 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.
Jan 15 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
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
Jan 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Jan 15 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
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
Jan 15 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
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?
Jan 15 2009
parent reply Eldar Insafutdinov <e.insafutdinov nowhere.com> writes:
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.
Jan 16 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
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."
Jan 16 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Sat, Jan 17, 2009 at 1:50 AM, Yigal Chripun <yigal100 gmail.com> wrote:


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


The need for the "handy" part doesn't go away.  Just the need for the
"compatible" part.

--bb
Jan 16 2009
prev sibling parent J Duncan <jtd514_ ameritech.net> writes:
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

 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....
Jan 16 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
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

 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
Jan 15 2009
parent reply Katrina Niolet <katrina niolet.name> writes:
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
Jan 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Katrina Niolet wrote:

 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.
 [...]
 P.S. You may have guessed this already, but I'm one of the developers
 working on QtD ;-)


I don't know Qt, so if you could do a writeup on exactly what D2 needs 
to support Qt, that would be most helpful.
Jan 16 2009
parent Katrina Niolet <katrina niolet.name> writes:
Walter Bright Wrote:


 I don't know Qt, so if you could do a writeup on exactly what D2 needs 
 to support Qt, that would be most helpful.


Yep, will do! Give me a few days on this please, I want to make sure I get
everything in there.
Jan 18 2009
prev sibling parent reply Sergey Kovrov <kovrov+digitalmars gmail.com> writes:
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
Jan 15 2009
parent reply Daniel de Kok <me danieldk.org> writes:
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).
Jan 16 2009
parent reply Sergey Kovrov <kovrov+digitalmars gmail.com> writes:
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.
Jan 16 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
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
Jan 16 2009
prev sibling next sibling parent J Duncan <jtd514_ ameritech.net> writes:
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-alie
s-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
Jan 16 2009
prev sibling parent Daniel de Kok <me danieldk.org> writes:
On Fri, Jan 16, 2009 at 11:42 AM, Sergey Kovrov
<kovrov+digitalmars gmail.com> wrote:

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


Actually, you are right, they use the theme API. I was under the wrong
impression, so they must be doing something right :).

Take care,
Daniel
Jan 16 2009
prev sibling next sibling parent J Duncan <jtd514_ ameritech.net> writes:
Bill Baxter 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


I just had the pleasure of informing my boss that we just renewed our 
$12000 worth of licenses for a soon-to-be-free product..... ah well...

Ive been using Qt for a couple years now and this is hands down the best 
cross platform development library on the planet. The way I see it this 
new license opens the world up to targeting a single platform: Qt - 
instead of windows, mac, linux, etc.

this could be a huge game changer
Jan 14 2009
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Bill Baxter 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...


There was Indigo, not exactly a port but a library to mimic Qt's API.
http://www.dsource.org/projects/indigo/

But that import is incomplete at the moment - I'll have to see what code 
I still have.  And maybe the project could be resurrected one of these days.

Stewart.
Jan 14 2009
prev sibling parent reply Katrina Niolet <katrina niolet.name> writes:
Stewart Gordon Wrote:


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


 
 There was Indigo, not exactly a port but a library to mimic Qt's API.
 http://www.dsource.org/projects/indigo/
 
 But that import is incomplete at the moment - I'll have to see what code 
 I still have.  And maybe the project could be resurrected one of these days.
 
 Stewart.


I'd say wait and see how the bindings work out. Long term a D port of Qt would
be great, but it would take several developers years to get any real percentage
of the Qt classes ported, and if the D bindings rock then there is little need
(other than just the desire to have to have Qt in a more modern language)

Katrina
Jan 15 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Jan 16, 2009 at 11:26 AM, Katrina Niolet <katrina niolet.name> wrot=
e:

 Stewart Gordon Wrote:


 Bill Baxter wrote:

 Qt 4.5 to be LGPL
 http://tech.slashdot.org/article.pl?sid=3D09%2F01%2F14%2F1312210

 Now we just need a D port...


 There was Indigo, not exactly a port but a library to mimic Qt's API.
 http://www.dsource.org/projects/indigo/

 But that import is incomplete at the moment - I'll have to see what code
 I still have.  And maybe the project could be resurrected one of these d=




ays.

 Stewart.


 I'd say wait and see how the bindings work out. Long term a D port of Qt =


would be great, but it would take several developers years to get any real =
percentage of the Qt classes ported, and if the D bindings rock then there =
is little need (other than just the desire to have to have Qt in a more mod=
ern language)

Is there an irc channel or mailing list or google groups list for
discussions and questions about qtd?


--bb
Jan 15 2009
parent Eldar Insafutdinov <e.insafutdinov nowhere.com> writes:
Bill Baxter Wrote:


 On Fri, Jan 16, 2009 at 11:26 AM, Katrina Niolet <katrina niolet.name> wrote:

 Stewart Gordon Wrote:


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


 There was Indigo, not exactly a port but a library to mimic Qt's API.
 http://www.dsource.org/projects/indigo/

 But that import is incomplete at the moment - I'll have to see what code
 I still have.  And maybe the project could be resurrected one of these days.

 Stewart.


 I'd say wait and see how the bindings work out. Long term a D port of Qt would
be great, but it would take several developers years to get any real percentage
of the Qt classes ported, and if the D bindings rock then there is little need
(other than just the desire to have to have Qt in a more modern language)


 
 Is there an irc channel or mailing list or google groups list for
 discussions and questions about qtd?
 
 
 --bb


#qtd on FreeNode
Jan 15 2009