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?


Scott Collins is the driving force behind open source QT, KDE and
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 ??


Just wrote to Scott because he is the QT man, and he came up in our
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.


Yes, but it would also be good if D was closer to D1.0. When D has less
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.


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.

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 ?


As far as I know, the most automated way is to have a macro tool that
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/


Won't happen for a while = ).
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 ??


 Just wrote to Scott because he is the QT man, and he came up in our
 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.


 Yes, but it would also be good if D was closer to D1.0. When D has less
 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 ?


 As far as I know, the most automated way is to have a macro tool that
 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/


 Won't happen for a while = ).
Feb 16 2006