Could Tk be D's ideal widget set?

[Anders F Björklund]

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)

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.

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

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

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 ?

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

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.

--anders