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
next sibling parent 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.

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


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

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

http://code.google.com/p/qtd/

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

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

http://code.google.com/p/qtd/

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

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.
Jan 15 2009
next sibling 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 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.

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.


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.

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.


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


the same GC callback that std.signals uses. Plus it's compatible with both Phobos and Tango. --bb

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

http://code.google.com/p/qtd/

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

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....
Jan 16 2009
prev sibling 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 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
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 next sibling 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
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 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 next sibling 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 next sibling parent 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 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
Jan 15 2009
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling 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 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 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