Could Tk be D's ideal widget set?

[Josh Stern]

On Tue, 10 Oct 2006 16:22:41 +0200, Anders F Björklund wrote:

> Josh Stern wrote:
> 
>>>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.
> 
> I was naively assuming that the library would eventually end up linking 
> to system libraries, and that those were the main ones involved here...
> But maybe Qt and GTK+ are more like actual system libraries (at least on 
> Linux) than graphical toolkits, though ? (i.e. comparable to Win32 etc.)

It depends what one means by system library:

1) Lowest stable API  - No, there are other layers below Qt and GTK+
that are API stable (libc/POSIX, X11, etc.), even across other Unix
flavors.

2) Lowest level technically or legally possible - No.

3) Provide basic GUI - Yes.  X11 and related libs don't provide standard
widgets that anybody uses today and only provide drawing primitives (like
lines and boxes), and don't determine look and feel policy.   On Linux,
look and feel policy is set by KDE and Gnome at an even higher layer.

4) Distributed with the OS and/or installed by Default - Depends, on the
specific Linux distro, but this is increasingly true for both.

5) Part of a Linux Desktop standard - Yes, getting there.  See
http://refspecs.freestandards.org/lsb.shtml




> I still think something smaller in ambition, like MinWin or FLTK 1.x, 
> would be nice to have around as an example of "all-D" GUI libraries ?

More examples of complex D libs of every type would be valuable.

>>>A *big* advantage of using the C++ Qt is that it can use system headers.
>> 
>> I missed your last point above...compared to what?  
> 
> Sorry, compared to a native port to D - which can't read C/C++ headers.
> (without first converting said headers to "D import modules" that is,
> something that is proving to be a lot of work for say Win32 or Carbon)

Okay, but making decent D bindings for the system headers on
platforms X,Y,Z is an order of magnitude easier than making a good GUI lib
from scratch for all those platforms, so I don't think *that* is a big
consideration (contrast that with the idea Walter put somewhere on his
site that ideally GC should  be  part of the OS).

>> 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.
> 
> A slight problem for D bindings is that SWIG support for D isn't 
> finished either, but there are others - like the bcd.gen project ?

Again.  Beefing up D in Swig is a much smaller project than a new GUI. 
But the issue remains for the Swig approach that the Swig interface files
need to be individually updated to track API changes in the underlying lib.


> As far as licensing goes, the two Qt editions are not interchangeable.
> So even if they do share a common "code base" (I'm assuming here that
> they are more or less identical),

Yes, they are explicitly the same code base.  In fact PyQt has a
commercial distribution and they tell people on their web site that end
users can use either the free or commercial Qt to dynamically link against
at runtime.

 they're more like forks of that base ?
> But I don't really know (nor care to) what the code differences are...

The "fork" idea is only about the restrictions TrollTech puts on the
commercial license "version" to help them have a viable business model. 
The commercial version is explicitly the same code but using a different
license.