Re: RE: GUI for Windows

At 11:40 6-3-03 +0100, Daan Leijen wrote:
>Hi all,
>
>>It seems to me that the way things usually make progress is if
>>
>>         * a small group         * writes a specification
I think this a good way to make progress, and I am willing to help with it. 
I would like to note that I do not have as much time available as some 
other people on this list seem to have, so one should not expect any 
implementation effort from my side.

Daan Leijen continues:
>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).
I agree with Daan about the potential problems, and I would like to 
emphasize that it is easy to underestimate the maintainance effort of any 
GUI library. In contrast with Daan, I think this is the main reason why 
this project should go for a portable API: it must be an open-ended, easily 
extensible GUI library with initial support for medium sized GUI 
applications. I think functional languages offer good tools to make this 
work. If such an API can't be made, then one might as well link in with an 
existing library.

>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.)
A point here is that the (full-fledged) functional API still needs to be 
designed unless one chooses a real thin interface layer. Such a solution 
would not profit from the expressiveness of a functional language, and 
should therefore only be chosen if no better solution can be found or 
agreed upon.

>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...
In summary: this project should yield a good functional design for a GUI 
API that is open-ended, and initially includes a (very) limited set of GUI 
elements (to encourage developers for making ports to their favourite 
platforms). However, in a sense this set should be 'arbitrary': they might 
as well have been included afterwards as 'plug-in's. No hardcoded prefab 
objects.

Note that this still allows a 'port' to a library that is portable on 
different platforms. If one can bear the "almost, but not quite, entirely 
unlike" platform look-and-feel, then that is OK.

>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!)
The Clean GUI project started on the Mac, and portable implementations for 
an early version have been made for Windows and X Windows (relying on 
OpenLook). This was the 0.8 version, named Clean Event I/O. The project had 
a significant redesign to version 1.x - and was renamed into Object I/O -. 
For this version there is a leading port to the Windows platform and we are 
working on a Mac port.

Peter Achten