[GUI] RE: GUI for Windows

[Daan Leijen]

Hi all,

> It seems to me that the way things usually make progress is if
>
> 	* a small group 	* writes a specification

I also believe that a small group would be good to get things
started or otherwise there will be too much talking and too little
working :-) However, I am currently wrapping up my thesis and will
be too busy in March to contribute. Afterwards (April), I can do my
share of work.

Having said that, I would also like to express my doubts about the
suitability of a common GUI specification -- I know, this is rather
strange as I have been one of the main advocates for a portable API!

I think that if we try to specify a full-fledged GUI API, it will
be too much work to implement it on different backends. The API will
be implemented partially, with bugs, misinterpreted, or not maintained.
As examples of items that would make the implementations difficult are
portable resource files, tool tips, tool bars, generic tree controls (on GTK), dockable windows, HTML (and openGL) rendering controls etc. Most are needed in larger applications and the lack of these items is one of the
reasons that only toy apps. are written these days. Some people on this
list think that we do have the resources to implement this all by ourselves, but I disagree -- portable toolkits like wxWindows and Qt have been in the works for years and with lots more development resources behind it, and even
they have trouble supporting most platforms satisfactory.

In my opinion, a common GUI specification only makes sense if we restrict
ourselves to a simple API that supports simple (medium sized) GUI applications.
A common denominator that is implementable with a reasonable amount of effort
on many backends -- a bit like GIO and the current ObjectIO library. It would
be good to have it, as it would create some order in the chaos of all the GUI
bindings that are around now and give the user some hope of transferring applications
easily between backends and platforms. On the other hand, it would always be a 'toy' API -- suitable for education and medium-sized applications (but I think
that is the best we can do with such an API).

My main point is that we should be more clear about the goals of the API as I feel that many discussions are just because of people having different goals
in mind -- like the whole resource issue.

All the best,
  Daan.

----

Another approach (that I favor) is to build a full fledged API on top of an existing full fledged library that is portable among all platforms. Libraries that come in mind are Java AWT, Tcl/Tk, Qt, and wxWindows. If Haskell is integrated with such library, it supports all gadgets you can ever wish and a Haskell developer will be on equal footage (is this english?) as C or Java programmer.
Other "little" languages have chosen this approach too, wxPython and PythonTk are big examples, but we also have wxPerl, wxEiffel and Tcl itself.
(Note that this approach doesn't preclude a common GUI API: the library will just
expose more functionality.)

One may worry that it is too much work to interface to these large systems
(as the haskell GTK binding has proved), but in the end I think it is less
work than trying to duplicate their efforts in Haskell. This is my main worry
with the GIO/Port library: it is just a lot of work to maintain different backends
and as soon as someone loses interest... I think that in some sense, the same
happened to the Clean ObjectIO library, started out on the Mac, than Windows and
now only windows is supported. (But it does show how useful it is to have at
least some standard medium level GUI around!)