Could Tk be D's ideal widget set?

[Anders F Björklund]

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

But if the "other library" (wx or tk or similar) only wraps the system 
libraries, then it feels like losing one wrapper layer could be a goal ?

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

I don't think so myself. I guess the people that are behind DWT did.
(then again I wasn't ever aiming for the state-of-the-art, either...)

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 ?

But porting all of the bigger libraries ? Does sound a bit expensive.
And as an old Mac user, I don't like the dual platform solutions much.

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

In wxD, all those pesky system libraries are only accessed by C/C++.
The D library code only needs to talk to the exported "C" functions,
so there is no need for access to all the system headers by D code.

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

We're holding SWIG as a "future goal" for wxD (and also for wx.NET),
and continue to work on the Perl/hand-generated classes meanwhile...

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

Cool, I wasn't really aware of all the details - thanks for the info.
(I've only played with the Trolltech Qt examples, not used it anything)

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

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), they're more like forks of that base ?
But I don't really know (nor care to) what the code differences are...

--anders