Could Tk be D's ideal widget set?

[Josh Stern]

On Tue, 10 Oct 2006 21:08:12 +0200, Anders F Björklund wrote:

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

Yes, because it is C based, using Gtk as an alternative to Win32 is a
little more similar in the code than using Qt as an alternative to Win32
would be.  Also, I believe that historically the first Unix version of
WxWindows used Motif, and that was OO C as well, so Gtk was already
conceptually close to their previous versions.

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

I don't think that raw X11 is that good for embedded since there are few
embedded X servers.  There is actually an embedded version of Qt that is
based on a frame buffer rather than an X11 model - it was used by Sharp
for instance in some of their products.   I'm not competent to discuss
the market share merits of different current approaches to embedded
semi-portability (including Micro-Java), but I would guess that PalmOS and
WinCE are important targets if that is the goal, and I'm not aware of
anything GUI toolkits that do a good job with both of these and the
regular desktop.


 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 ?

Because Linux GUI apps can come from so many sources, it's very debatable
to say what if anything the "native look and feel" means on Linux at the
present time (at one stage it meant the Motif look on most Unix, but that
was never standard on Linux and definitely uncommon today).  Both KDE and
Gnome offer systems for run-time configuration of fonts, colors, rendering
plugins, etc. in all currently running Gnome or KDE apps.   They have also
talked to each other about standard to let non-toolkit apps participate in
this process and to shared DND for things other than text.  The place to
look at the current theoretical status of those standards is here:
http://freedesktop.org/wiki/
http://portland.freedesktop.org/wiki/

On X11, the window manager that is running decorates the outside of
windows.   So, say, if I am running KDE as my desktop environment (with
the Kwin window manager) and a version of Firefox that is built against
Gtk, then when I update my desktop window manager decorates, it affects
the colors of the borders of the Firefox window but not inside the app.
Similarly I can change the default text font for all running KDE
applications but I can only change the header font from KDE for the text
above the border of Firefox and need to go into Firefox itself to
configure the fonts it uses for web pages. The stuff above would like to
make all of that happen together even for apps built on different
toolkits.   I'm not one the people who thinks this is a very important
issue.   


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

It's only more of an obstacle if you expect the GUI toolkit headers to
change more often (or if they are much larger) and you want to track those
changes - i.e. easily update to Qt5 if and when it comes out.

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

Editing interface files is editing code.   But if you have parsing code
and auto-generation from the rep of just what is parsed, then that is more
automated.


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

Hopefully WxWindows can eventually take advantage of the gtk
pluggable rendering engines to allow whatever look and feel the user wants
(at least as far as that is supported by a set of plugins).