[GUI] RE: GUI for Windows

Thu, 06 Mar 2003 13:12:27 +0100

--=====================_9729696==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

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

--=====================_9729696==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 11:40 6-3-03 +0100, Daan Leijen wrote: 
<blockquote type=cite cite>Hi all, 
 
<blockquote type=cite cite>It seems to me that the way things usually
make progress is if 
 
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>* a small
group <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>*
writes a specification</blockquote></blockquote>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: 
<blockquote type=cite cite>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).</blockquote>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. 
 
<blockquote type=cite cite>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 &quot;little&quot; 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.)</blockquote>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. 
 
<blockquote type=cite cite>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... </blockquote>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 &quot;almost, but not quite,
entirely unlike&quot; platform look-and-feel, then that is OK. 
 
<blockquote type=cite cite>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!)</blockquote>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 
</html>

--=====================_9729696==_.ALT--