Could Tk be D's ideal widget set?

[Jeff]

Before I reply, I should probably note that I didn't mean to come across 
as if I were claiming any authority or expertise on UI toolkits in 
general, so I'm sorry if I did; my comments were mostly just my personal 
opinion from my limited experience.

Josh Stern wrote:

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

By "really take advantage of D's features", I only meant that a faithful 
translation of an existing OO windowing toolkit wouldn't really have 
much room to play with D's features, since it would be expected to 
behave in an all but identical manner to the original (so why not just 
use the language in which it's already written?).

As far as D wrappers for existing toolkits are concerned, I'd be much 
more enthusiastic about these than attempts to translate (and keep 
up-to-date and clean), say, SWT. "DUI"/"DUIT" started looking like a 
pretty attractive idea once the decision was made to just focus on being 
a GTK wrapper (rather than using native controls on each target 
platform), and I guess I could be happy using a GTK wrapper now that it 
seems to work pretty well on Windows. I'm yet to see a QT application 
that doesn't look horribly ugly to me. I'm sure it's a quite capable 
toolkit, but it's hard to feel good about using it given that. (Once 
again, personal opinion only, there).

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

I don't have a full answer to that given my total lack of experience 
writing windowing toolkits... but if proven concepts could be taken from 
multiple other toolkits rather than trying to clone one exactly, we 
wouldn't need to be playing catch up to the original, could try to 
simplify some things by making use of D's delegates, templates, S&S 
mechanism (if that goes ahead), etc. Ideally it would be nice to have 
something usable that was competitive with existing toolkits, but even 
this didn't happen, I wouldn't consider the venture a complete waste.

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

I don't disagree. I'm just saying what I'd like if the decision were 
already made to write a new toolkit in D; not trying to justify such a 
decision.

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

This is just part of a vague wish list. The idea of having lots of more 
advanced pre-built components standard really appeals to me. For 
example, I'd often want to present an error message to the user with 
some advanced information available that would not normally be desired. 
To keep it clean, it would be good to have an expandable section. If 
this kind of dialog was available stock, then users of the toolkit would 
be more likely to take advantage of them than if they had to write it 
themselves.

As for architectural limitations... none that I can imagine (see above).

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

Sorry, I didn't mean to imply that it should be a standard GUI toolkit 
for D. By that I just meant that it would be worth waiting to see where 
the D standard library ends up going (rather than being too eager to 
start developing a new toolkit now) to so it and v1.0 of the D spec 
could be taken advantage of, rather than potentially duplicating a lot 
of more general functionality, or failing to utilise features that may 
be added to the spec before v1.0.

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

Example: over-complicating relatively common tasks, such as hooking up 
signals and slots. Even if the S&S mechanisms that were being discussed 
a while back don't find their way into the language, wouldn't D's 
delegates help to simplify S&S somewhat anyway?

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

That comes only from my personal dissatisfaction with a lot of the 
toolkits that are available for which D wrappers could be made (yet 
appreciation of many of their features, and of toolkits for which D 
wrappers could /not/ be made). I was wondering if anyone else felt the same.