Whither DWT?

[Charles Hixson]

DBloke wrote:

> Hi,
> 
> The D community seems to be divided regarding a GUI/Framework for D.
> I guess the community needs to decide exactly what it would like from a
> GUI/Framework.
> 
> Are we looking for
> Portability to multiple platforms?
> 
...
> 
> DBloke

-- 
Work in progress

>From my personal perspective, it needs to work well on my personal system,
which runs Linux.  It also needs to be easy to set up (or come with the
compiler), because I'm not *committed* to D.  I just want to get my project
done, and D would be a nice tool.

In the longer term, I would also want the GUI to work on the Mac.  I'm
indifferent to MSWind, but I'm fairly certain that it would happen if it
were at all feasible, so that doesn't need much thought.

Better to start with a simple framework that can later be expanded, and get
it working WELL.  (Simple means being able to do dialog boxes.  Ability to
use input from a GUI builder, like glade, or SpecTCL would be a real plus,
no question, but is LESS necessary that having a solid system.)

For my personal interest, I would like an enhanced version to be able to
draw on canvases, display pictures from multiple file formats (including
animated gifs), do sound, etc.  I don't think of these as features that
should be present in the original version...even though without them I
would need to find a different language.

KISS is a really good motto.

Another good feature would be documentation that says exactly which features
are supposed to be working.  I looked over wxD, and found it interesting,
but the only way to find out what was expected to be working would appear
to be to install it and try.  In this respect a well annotated stress test
setup would be very useful.  (Think of DStress as a checklist of what is
working in D.  It's not good user documentation, but it would be a good
basis for automatic creation of a status page of user documentation. 
[Maybe it does that...I've been looking at so many options I've rather lost
track.])

Also needed is a good way to report bugs.  I think the capability for this
is built into dsource, though I haven't tried to use it, since mainly I've
been studying and evaluating rather than developing.

I would have liked it a lot if I had been able to choose D, but it looks to
be too green yet, and this is mainly the libraries, but not entirely. 
E.g., when I tried dmd -o test test.d `gtk-config --libs` the compiler
complained about the -l files.  Not good.  I might have checked out gcd,
but there were other problems that ruled D out of the running, so I didn't
bother.

Currently, you need to have a project that is adapted to the existing
compiler and libraries, rather than adapting the compiler and libraries to
the project.  (That's awkward, and doesn't sound like what I mean, but I
can't think how to be clearer.  Lets try again...)  A language needs to be
a general purpose tool, able to be adapted with minimal effort to a wide
variety of problems.  One of the big tools to allow this is pre-existing
libraries.  This means either the libraries are built for that language,
or, alternatively, it is *VERY* easy to import them from and alternative
language.  Otherwise the problems that the language can be used for with
reasonable efficiency is quite limited.  One language that is often used as
a base for libraries is C, but unfortunately the use of macros in C header
files tends to make importing C libraries quite problematical.  Very few
languages have a decent way to do this.  Most of those that do generate C
as an intermediate code.  Languages with a long history and large user base
tend to acquire a number of useful libraries in a form native to the
language.  There is such a strong correlation (isomorphism?) between having
a large set of libraries and being a well established language that it's
probably impossible to say which caused the other, but it's reasonable to
suspect a feedback relationship.

The first step, always (AFAIK), is to start with a few specialized libraries
and a broad class of rudimentary but sturdy libraries.