Could Tk be D's ideal widget set?

[Josh Stern]

On Tue, 10 Oct 2006 21:21:43 +1000, Jeff wrote:

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

Sure.  And before I read what you write below, let me clarify that
whatever comments I made about writing a new GUI toolkit being a
tremendous amount of work would apply equally even if you were the
greatest GUI toolkit writer on the planet.   Let's assum for argument sake
that you are...


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

I'm still not following what limitations you are talking about.   Can you
clarify with an example or two?  

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

Personally I like the look of KDE (all Qt apps) better than Gnome (all
Gtk apps), but I know that lots of other people feel the opposite - it
seems like close to a 50-50 split on this.  Fortunately they are both
moving close to being able to give the same look and feel as the other, so
it probably doesn't make sense to base the choice for a new API on looks.


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

See my remarks at the top.  I'll elaborate very briefy on two cases:

Case 1 - totally from scratch in all respects - an *incredible* amount of
work that is mostly language neutral.

Case 2 - start from an existing codebase and port/translate as you go -
still a huge amount of work, you may inherit some license restrictions,
and you may inherit a lot of design decisions while introducing new bugs. 
Is it really worth it?

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

Right, it would  be fun and educational.   Just be clear in the
beginning if that is okay as a goal.


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

Okay.  As an aside on this topic -  there are many people who advocate
the opposite wrt to achieving native OS look and feel.   I believe that
WxWindows is a leading advocate of the opposite approach where one tries
for native look and feel by re-using native widgets wherever possible.



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

They help mainly in the library code (that app developers normally don't
see).  Java style weak references would help more if they somehow found a
way of sneaking into D :)

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

Every lib has some limitations.   But its worthwhile to think carefully
about which limitations that bother you are based on lib decisions you
don't like, which are based on missing features that could be added, and
which are based on the application language (which can  be changed with
bindings).