Could Tk be D's ideal widget set?

[Anders F Björklund]

Josh Stern wrote:

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

What I was trying to say was that the toolkits I have been looking at
are targetting GTK+ as a "platform" in the same way as Win32 or MacOS.
So it's been more about GTK+ as the system library, than about porting
or using GTK+ on another platform - even if that would have worked too.
So even if GTK+ is cross-platform, it is treated as just another OS lib.
(I think that this goes for Qt as well, but I don't know all about it...
Not sure if there is a wxQt port, but otherwise that could be similar ?)

This has worked well for me, the Linux version uses the "native" widgets
in the same theme as the rest of the desktop - and so does Win and Mac.

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

For wx we have "wxX11" which uses the "Universal" (lightweight) widgets 
that provides a (limited) highlevel interface for such platforms. Maybe 
not so interesting for "raw" X11, but it also works for embedded so...

But for the full featured version, then having GTK2 is my requirement.

> 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

The two distributions I have in mind, Fedora Core 5 and Ubuntu Dapper,
both use GNOME as their default desktop - so GTK2 is my target there.

Both offer KDE and Qt as well, and integrated both in the distribution 
and as per standards and projects you are referring to - a good thing.
So requiring either GTK+ (2+) or Qt (4+) is not a problem, I think...

For now I've chosen GTK+, maybe Qt would have been closer if I used KDE.
I understand that just like Swing it doesn't really use native widgets,
but that they have hidden that fact well by providing a look-and-feel ?

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

Sure, I wouldn't mind at all seeing for instance DWT finished either...
Just that those two were the ones in D that I looked more at (for GUI).

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

Yeah, until we can have it fully automated (maybe with a patch or two)
it's mostly a question of plain old boredom and restrictive licensing.
At least for the Win32 and MacOS headers, it's tedious to translate for
potential troubles with legal issues with any redistribution thereof.
(but "WindowsAPI" and "CarbonHeaders" projects are doing those two OS)

For things like GUI libraries, it's usually enough to "port as needed".
(i.e. just adding extern(C) statements for all system functions needed)

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

Yeah, it's no more of an obstacle than what the missing OS headers are.
It's just that these little things tends to add up, as they take time ?

But the SWIG approach is probably better in the long run anyway, since
it's at least easier to adapt to API changes than having to edit code ?

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

Okay, but from their info it looks like you must decide before using it.
The dual licensing model is not uncommon, and much better than closed...

And licensing is just one of the reasons I am sticking with wxWidgets.
 From what I saw of Qt4 when I tested it briefly, it looked great to use.

--anders