Could Tk be D's ideal widget set?

[Josh Stern]

On Tue, 10 Oct 2006 09:17:33 +0200, Anders F Björklund wrote:

> Josh Stern wrote:
> 
>>>But if you want to port Qt over to D, then by all means go for it! :-)
>> 
>> Porting Qt itself is both too much work and undesirable (because it would
>> be a fork).  What I discussed a few posts back was porting the PyQt or
>> QtJava bindings for Qt (which link with the regular Qt libraries).
> 
> Actually this was what I meant, "make it accessible from D", not port.
> 
> I mean, having a library written in D is still a nice future goal and I 
> think the current DWT is not a bad choice for such a big porting effort. 
> (Java, or even C#, is actually easier to port to D - than what C++ is)

"Nice" is hard to argue with.  I mean, running on an OS that had a native
D API might also be "nice" (in the way LISP machines were nice for LISP). 
But saying that therefore trying to write a new OS, or at least a new
libc, in D is the right way to go is whole different kettle of fish.
Clearly writing a state of the art GUI lib from scratch is not nearly as
hard as writing a state of the art OS and drivers from scratch and the
issue of incompatibility with existing GUI libs is not nearly as important
(though not totally irrelevant), but its still an incredible amount of
work.  One really needs to think hard about whether the manpower resources
are available to do that and whether the ultimate payoff justifies it.

> But in the meantime, being able to use the standard GUI libraries from D 
> would be nice as it is currently an advantage that C++ or even Java has. 
> And D wrappers for Qt are missing AFAIK, we "only" have them for GTK+...
> 
> A *big* advantage of using the C++ Qt is that it can use system headers.

I missed your last point above...compared to what?  

>> These
>> are both a) much, much smaller, and b) 90-95% auto-generated from Qt
>> headers, so a lot of the work would be just modifying the generator
>> programs and then adding support code - they are both designed to be
>> readily updated to future Qt release.  The biggest hurdle
>> I can see would be figuring out the best naming and documentation
>> convention for dealing with the situations where Qt makes use of more
>> member function overloading than what D allows.  
> 
> The QtJava files look similar to how the current wxD bindings work, 
> while PyQt seems to use a more SWIG-like (.sip) automated approach...
> 
> I'm not sure which approach would work best for QtD/QDt, but we're 
> moving towards the second method in wxD as it is more maintainable.

QtJava looks more elegant to me personally (and Trolltech seems to like
it too as they have now turned it into an actual product of theirs called
QtJambi).   But I hesitated to state a preference because I believe QtPy
has been more widely used and because the issue of Java's closer C++
compatibility wrt function overloading will be one extra issue to overcome
(whereas QtPy takes the approach of more often using strings explicitly 
(e.g. for signals) to name the C++ binding target.

Most of the people working in this area seem to say that they started out
with the idea that using Swig would be the way to go and then discovered
that it was hard to maintain.   I'm not sure how much of that is still
true now that Swig is a lot more mature.   But talking about Swig gets us
to three different header parsers as a starting point:  gcc-xml (PyQt),
Swig, and Kalyptus (QtJava).   QtJambi probably has its own
specialized parser that would be updated by TrollTech, but I haven't had a
chance to look at that.


> There is also a Qt# project: http://qtcsharp.sourceforge.net/
(GPL)
> (this one also used a Perl program to generate the initial C# files)

Yes, the Kalyptus tool that generates QtJava also generates Objective-C
and there are QtRuby bindings that take a slightly different approach as
well.   At one time there was a hand-generated QtPerl, but that
was obviously something that ran into difficulties being updated to each
new Qt release so I'm not sure about its current status.


> Doing a proof-of-concept spike would probably show which approach
would
> work better for the D bindings/wrappers, maybe even try both of them ?

Yes, or at least look carefully at all the existing methods.

>> The Qt commercial licensing fee is only relevant if one needs to
>> distribute a closed source app outside of your organization.
> 
> Or use any "open source" license other than the GPL, for instance. I
> don't have a problem with GPL at all, but LGPL is easier to use.

Agreed.  It' worth pointing out that the restrictive parts of GPL apply
only to the act of program distribution and there is an exception for
linkage against system components - that is components that are
distributed with the OS platform.   So GPL doesn't affect internal
projects that stay internal to an organization and Qt is moving close to
being a system component on on Linux, at least.

> But I do think that the Community Ed. and
Commercial Ed. are two
> separate Qt products, so they would be more like forks in practice.

I guess you mean the code that one develops using each. Right?  That seems
to be TrollTech's idea.   I wonder whether people have ever tried to
negotiate back payments to grandfather code that started developing with
the open source product and what TrollTech's response was.