Could Tk be D's ideal widget set?

[Josh Stern]

On Mon, 09 Oct 2006 17:57:22 +1000, Jeff wrote:

>> I think a GUI for D should be written with D in mind from the start.
>> I didn't look at tk/tcl/whatever-it-is-called, but just when you say 
>> that it's written in C, this says to me it's not what D should adopt as 
>> an official gui library.
>> 
>> Having said that, I'm personally of the opinion that Harmonia is the GUI 
>> library that has the most potential.
> 
> I agree; I can understand that people want GUI libraries for D available 
> as soon as possible, and indeed there are people working on such 
> projects (i.e. D bindings, ports and/or OO abstractions for existing 
> toolkits). However, if we really want some thing /good/ and maintainable 
> that can really take advantage of D's features, then starting from 
> scratch seems like the best path to me.

After the above, I was expecting to see some description below of what it
means to "really take advantage of D's features" but I didn't find it, so
I'm really unsure.   It's clearly important for D that new application
code written in D should be able to sub-class objects/widgets in D and
have access to the full programming API, but if the bindings are done
correctly and the underlying widget set has good OO then it isn't
necessary for the underlying widget set to be written in D.  In
particular, PyQt and QtJava provide examples of this possibility.  So what
is the real idea?  


> Even if progress was to be fairly slow, surely I'm not the only one
who
> would be enthused enough by such a project to maintain interest?
> Remember, this wouldn't rule out using other toolkits in the meantime,
> but could also provide us with a /really/ good one in the long run.

What is meant by the long run depends on the target feature set.  Already
something like Tk or WxWindows or Qt has an incredible number of man-years
invested and new development continues.   That's not to say anything
negative about the educational and/or fun benefits of writing a new widget
lib from scratch so long as one is clear that the purpose if fun and/or
education.   But if the goal is a superior end product, especially if
achieving that goal is essential to the fun, then a lot more needs to be
said about how and why that might happen.


> For anyone interested, the (utopian? <g>) vision I've had in my mind for
> some time of a fresh D windowing toolkit would be:
> 
> - Minimal use of native windows/widgets (only for top-level, and other
> cases where really needed?); a Swing-esque approach could be taken to
> native look and feel (making it "somebody else's job"); stops the
> responsibilities getting too tangled, and it seems to have worked pretty
> well for them.

Both Gtk and Qt have converged on methods to allow pluggable look and
feel.  If some aspect of their current ability in this category is
lacking, fixing it directly would be the straightest path.  Gnome and KDE
have parallel and increasingly interoperable methods for telling a set of
applications to conform to the same updated look and feel at runtime.

> - Well-defined basic components that everyone expects (all the buttons,
> menus, etc.) but also /eventually/ packages containing more complex
> components (e.g. pretty message dialogs with cleanly expandable "more
> info" sections, headers and footers; colour, date selection dialogs;
> etc.). Saving people from recreating common widgets (formatted text
> areas) could really set it apart from the rest, and people not working
> on the core architecture of the library could certainly lend a hand
> here.

This sounds like policy stuff ath the desktop (Gnome or KDE) level. 
Parallel questions to the above here is "What are the architectural
limitations of gtk ot Qt that you see as limiting what you want to do here?


> - Developed along-side the D standard library which will no doubt
> (?) be getting a lot more attention once v1.0 of the D spec is out. - It
> would be nice if it could take advantage of existing cross-platform
> libraries where possible (e.g. pango for advanced text rendering, etc.),
> but maybe not too practical?

Trying to specify a single "standard" GUI toolkit for D is probably not a
good idea.   Java had a lot more reason than D for trying to do this
(goals of sandbox security capability abd hyper-portability) and still
suffers a lot as a desktop tool because they got it wrong twice. 

> - Drawing inspiration from Swing, SWT, GTK(gtkmm), QT and other
> toolkits, whilst noting what design traps can be avoided due to D's
> language features.
> - The will to Do It Right, no matter how long it takes. We should be in
> this for the long haul.

What are the design traps you think D will allow you to avoid?

> Does anyone else think it would be worth it, or are most people content
> to try to tap into existing toolkits through D?

I'd like to understand the concrete ideas that justify the wording
"content".