www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Reply from Scott Collins

reply nick <nick.atamas gmail.com> writes:
Scott Collins replied to my question regarding GUI toolkits. What do you
think?


He writes:

First, I think it is _much_ better to use an existing toolkit than to
write your own.  Second, I honestly think that Qt is the best GUI
toolkit out there.  Given that, there are two different directions you
could go here:

  (1) port the existing GPL Qt to D (but that means all DQt work would
be GPL)
  (2) develop bindings to Qt from D (but that means developers have to
choose between GPL and proprietary)

I think (1) is not much better than writing your own toolkit from
scratch.  You'll force users to choose the GPL, and you'll always be
playing catch-up.  There are at least four concurrent efforts creating
bindings for Qt to other languages: PyQt; an external set of Java
bindings;  our announced developer preview of Java bindings developed
internally; and our internally developed EcmaScript bindings.
Additionally, I'm aware of at least one other project that uses
home-grown bindings to Qt for their own language.  I think this is
evidence that bindings to other languages are possible/reasonable.  This
makes me feel that (2) is really the best choice.

I think having bindings to Qt in D is a good idea, one I could
personally support.  I think it's something you could do even without
Trolltech's help; but I'd like to get Trolltech behind you to whatever
extent possible to ensure your success ... though I'm not sure what you
might need that TT can provide.  It's unlikely TT will have any
available engineering time to devote to this, beyond at least a few
hours for discussing things with you and any other D developers on the
project.  I don't think you guys need proprietary licenses to proceed
(but if you did, we could probably work something out).  Use of the
final product would be much as with PyQt: PyQt users who want to live by
the GPL can use the GPL Qt libraries gratis; otherwise, they purchase a
commercial developer seat, just as a GPL-averse C++ developer would.
Our interaction with the PyQt effort is essentially: we don't get in
their way or intentionally break them.

I'm interested enough that I intend to learn D right away.  What else
can I do to help?  How do you see Trolltech's involvement?

Cheers,
__________
Scott Collins
Feb 13 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dsri4i$iv8$1 digitaldaemon.com>, nick says...
Scott Collins replied to my question regarding GUI toolkits. What do you
think?

Who's Scott Collins?
He writes:

First, I think it is _much_ better to use an existing toolkit than to
write your own.  Second, I honestly think that Qt is the best GUI
toolkit out there.  Given that, there are two different directions you
could go here:

  (1) port the existing GPL Qt to D (but that means all DQt work would
be GPL)
  (2) develop bindings to Qt from D (but that means developers have to
choose between GPL and proprietary)

I agree that 2) would be the way to go to get Qt in the hands of D developers quickly along with provide licensing flexability. But what would 2)'s alternative be to the moc pre-processor and language extensions Qt requires for C++? How does PyQt do things? I for one would be an extremely hard sell if a code generator had to be used and/or separate code files had to be generated and included as part of the build process. I know this has been an argument that Qt has been struggling with for years now, and that plenty of C++ Qt users seem to be able to successfully deal with it. But I also get the feeling that quite a few other C++ users have written Qt off because of it - like I said, I'd be a hard sell on D Qt bindings if I also had to carry the moc and qmake baggage around. Thanks, - Dave
Feb 13 2006
next sibling parent nick <nick.atamas gmail.com> writes:
Dave wrote:
 In article <dsri4i$iv8$1 digitaldaemon.com>, nick says...
 Scott Collins replied to my question regarding GUI toolkits. What do you
 think?

Who's Scott Collins?

TrollTech's open source friendliness. http://www.trolltech.com/developer/scottcollins.html If you are not familiar with QT or TrollTech, I suggest you peruse their site. People truly love their software.
 
 He writes:

 First, I think it is _much_ better to use an existing toolkit than to
 write your own.  Second, I honestly think that Qt is the best GUI
 toolkit out there.  Given that, there are two different directions you
 could go here:

  (1) port the existing GPL Qt to D (but that means all DQt work would
 be GPL)
  (2) develop bindings to Qt from D (but that means developers have to
 choose between GPL and proprietary)

I agree that 2) would be the way to go to get Qt in the hands of D developers quickly along with provide licensing flexability. But what would 2)'s alternative be to the moc pre-processor and language extensions Qt requires for C++? How does PyQt do things? I for one would be an extremely hard sell if a code generator had to be used and/or separate code files had to be generated and included as part of the build process. I know this has been an argument that Qt has been struggling with for years now, and that plenty of C++ Qt users seem to be able to successfully deal with it. But I also get the feeling that quite a few other C++ users have written Qt off because of it - like I said, I'd be a hard sell on D Qt bindings if I also had to carry the moc and qmake baggage around. Thanks, - Dave

All the points you raised are very valid. It may, in fact, be better to use DWT as an initial effort. However, it is always good to get an expert's opinion. Furthermore, Scott Collins' interest may prove to be a very positive influence on the D community and D's success.
Feb 13 2006
prev sibling next sibling parent John Stoneham <captnjameskirk moc.oohay> writes:
Dave wrote:
 
 Who's Scott Collins?
 

From the Trolltech website: "Qt / Open Source Evangelist: Scott Collins Scott Collins is an engineer, public speaker, technical evangelist, and one of the voices of the Open Source community. [...] Collins' technical depth and breadth, coupled with his skill at clearly communicating even the most challenging concepts, have made him a popular speaker around the globe on topics from the technical to the historical, social, and political ... often all in the same speech, illuminating the connections between." Personally I feel that this is somebody we DEFINITELY WANT on our side. It is a fantastic sign that he's interested enough that (he says) he's going to pick up D! I'm sure that once he does, coming from a C++ background he can't help but fall in love with D, so who knows where this will lead.
 But what would 2)'s alternative be to the moc pre-processor and language
 extensions Qt requires for C++? How does PyQt do things?
 
 I for one would be an extremely hard sell if a code generator had to be used
 and/or separate code files had to be generated and included as part of the
build
 process.
 

PyQt is a beast. It is a set of C++ module extensions for Python along with a Python interface with "300 classes and over 5,750 functions and methods" according to the docs, and takes about 10 minutes to compile (granted, their FAQ is a little dated). Most of the documentation on their site is about the binding for QT3 which doesn't have the Open Source license for Windows, so don't be surprised if you browse the site an see that a commercial license has to be purchased for Windows. QT4 has an Open Source license and there is a snapshot of PyQt4 available. If a D binding was begun, it would of course start with Qt4 and it's Open Source advantages. I'm not 100% sure, but I don't think you need moc or qmake at all to use PyQt. I believe you need both to *compile* PyQt, but not with a pre-compiled PyQt package used to develop your own project. I know that PerlQt doesn't need them, but again I believe they are needed to compile PerlQt from source. So, to USE a DQt binding you wouldn't need moc or qmake, assuming that the binding was designed properly (delegates could be used to fill in the slots/signals which moc sets up, similar to the way PerlQt adds functions on the fly). However, I'm sure both would be necessary to compile the binding from source. --john
Feb 14 2006
prev sibling parent reply "Craig Black" <cblack ara.com> writes:
Two things, one, how do we get in touch with this Scott Collins guy if we 
have a question for him?

I would also like to reply to this.

 I for one would be an extremely hard sell if a code generator had to be 
 used
 and/or separate code files had to be generated and included as part of the 
 build
 process.

 I know this has been an argument that Qt has been struggling with for 
 years now,
 and that plenty of C++ Qt users seem to be able to successfully deal with 
 it.
 But I also get the feeling that quite a few other C++ users have written 
 Qt off
 because of it - like I said, I'd be a hard sell on D Qt bindings if I also 
 had
 to carry the moc and qmake baggage around.

I have a number of years of experience with Qt. Moc'ing does have a slight impact on code size, but nothing overwhelming. However, Qt's slot/signal approach can actually decrease memory footprint because when there is no overhead per instance of a class. As far as speed, Qt is incredibly efficient. They have their own library of container classes that are very powerful and elegant. Qt is the best GUI because it is fast, has the most capability, and is cross platform. The ability of Trolltech to both generate revenue and get support from the open source community has had a huge impact on the quality of the product. There will always be those who don't like Qt for whatever reason, but all things considered, it is still the best. (Trolltech should be paying me for this!) -Craig
Feb 14 2006
parent reply nick <nick.atamas gmail.com> writes:
Are you working on a QT-D port/bidnings? You can contact him by email -
just google for his name.

Craig Black wrote:
 Two things, one, how do we get in touch with this Scott Collins guy if we 
 have a question for him?
 
 I would also like to reply to this.
 
 I for one would be an extremely hard sell if a code generator had to be 
 used
 and/or separate code files had to be generated and included as part of the 
 build
 process.

 I know this has been an argument that Qt has been struggling with for 
 years now,
 and that plenty of C++ Qt users seem to be able to successfully deal with 
 it.
 But I also get the feeling that quite a few other C++ users have written 
 Qt off
 because of it - like I said, I'd be a hard sell on D Qt bindings if I also 
 had
 to carry the moc and qmake baggage around.

I have a number of years of experience with Qt. Moc'ing does have a slight impact on code size, but nothing overwhelming. However, Qt's slot/signal approach can actually decrease memory footprint because when there is no overhead per instance of a class. As far as speed, Qt is incredibly efficient. They have their own library of container classes that are very powerful and elegant. Qt is the best GUI because it is fast, has the most capability, and is cross platform. The ability of Trolltech to both generate revenue and get support from the open source community has had a huge impact on the quality of the product. There will always be those who don't like Qt for whatever reason, but all things considered, it is still the best. (Trolltech should be paying me for this!) -Craig

Feb 14 2006
parent "Craig Black" <cblack ara.com> writes:
 Are you working on a QT-D port/bidnings?

No. I don't have a lot of spare time. But I would be very interested if such a project existed. I might be able to help with testing or small stuff. -Craig
Feb 15 2006
prev sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
Hi Nick

I am wondering if you are writing to 
all the GUI gurus or only to Scott Collins ??

It might be a good idea to get options from different central people.
And use it as a change to tell them about D.


The most important thing I would like from a DUI library is 
that it make unit testing your UI code easy.

How does SWT, QT add the others GUI tool-kits fill that demand ?


Here is some examples of what I would like a DUI to do. 
http://mrl.nyu.edu/~jhan/ftirtouch/
Feb 15 2006
parent reply nick <nick.atamas gmail.com> writes:
Knud Sørensen wrote:
 Hi Nick
 
 I am wondering if you are writing to 
 all the GUI gurus or only to Scott Collins ??

previous debates.
 It might be a good idea to get options from different central people.
 And use it as a change to tell them about D.

problems, it will be easier to get the GUI experts interested. Scott is an exception in that he is very devoted to the open source movement.
 The most important thing I would like from a DUI library is 
 that it make unit testing your UI code easy.

Atif Memon at the University of Maryland does research in automated GUI testing. He has applications that tear apart a Win32 or Java app and create a tree/graph of possible user interaction. Then the app selects some paths in the tree/graph and clicks through them. It's pretty impressive stuff. Here is the project page: http://www.cs.umd.edu/~atif/GUITARWeb/ Here is Atif Memon's page: http://www.cs.umd.edu/~atif/newsite/index.htm
 How does SWT, QT add the others GUI tool-kits fill that demand ?

records user interaction and then repeats a recorded interaction for the purposes of a regression test. Yeah, it sucks. I really don't know of anything much better that's being used in the industry at the moment.
 Here is some examples of what I would like a DUI to do. 
 http://mrl.nyu.edu/~jhan/ftirtouch/

Feb 15 2006
parent =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Wed, 15 Feb 2006 20:22:36 -0800, nick wrote:

 Knud Sørensen wrote:
 Hi Nick
 
 I am wondering if you are writing to 
 all the GUI gurus or only to Scott Collins ??

previous debates.
 It might be a good idea to get options from different central people.
 And use it as a change to tell them about D.

problems, it will be easier to get the GUI experts interested. Scott is an exception in that he is very devoted to the open source movement.

The are other which is devoted to open source like the gtk and enlightenment guys. If we ask the advise on a GUI now might be the right time.
 The most important thing I would like from a DUI library is 
 that it make unit testing your UI code easy.


I am not talking about unit testing of the GUI library but about a easy way to test the code you write to interact with the GUI library. This means writing the GUI library using interfaces so that the programmer can use mock objects to test hes code.
 GUI testing is inherently difficult. If you are interested, professor
 Atif Memon at the University of Maryland does research in automated GUI
 testing. He has applications that tear apart a Win32 or Java app and
 create a tree/graph of possible user interaction. Then the app selects
 some paths in the tree/graph and clicks through them. It's pretty
 impressive stuff.

Automated tests is not a replacement for unit testing because it don't force the programmer to write good testable, modular and decoupled code.
 
 Here is the project page:
 http://www.cs.umd.edu/~atif/GUITARWeb/
 
 Here is Atif Memon's page:
 http://www.cs.umd.edu/~atif/newsite/index.htm
 
 How does SWT, QT add the others GUI tool-kits fill that demand ?

records user interaction and then repeats a recorded interaction for the purposes of a regression test. Yeah, it sucks. I really don't know of anything much better that's being used in the industry at the moment.
 Here is some examples of what I would like a DUI to do. 
 http://mrl.nyu.edu/~jhan/ftirtouch/


Feb 16 2006