[GUI] GUI meeting at ICFP?

[Axel Simon]

On Thu, Jul 24, 2003 at 09:23:42AM +0100, Simon Peyton-Jones wrote:
> | on my side). In hintsight this was a very negative
> | development as it encouraged people to follow their own
> | convictions and implement their ideas in the hope that their
> | approach is adopted by the masses.
> 
> I don't think that the recent work on GUI implementation is a negative
> development at all.  Its great!  It gives new information about what
> works and what doesn't, and it adds to the raw material from which
> something common can be forged.  

The more material (aka backends) there are, the more difficult it is to join 
them. The main concern about wxWindows was that it doesn't give native 
look-and-feel on every platform - in fact people came to the conclusion that 
this is impossible. Hence the following idea (sorry for the repitition):

- create a "Common API" that captures common aspects of major platforms (Win,
Mac, Gtk) without violating native look-and-feel.

- give the user the possiblity to use platform specific functions for 
everything that is not captured by the Common API in a non-portable way. 

You could adapt other backends (like wxWindows) exposing this Common API,
but where is the point when you have native backends?  You could use
HToolkit which is a Common API for Win and Gtk but will fail to be portable
to Mac, so do you live with that and run the Gtk version in the Xfree
server for Mac?

Most people will be very frustrated once the community settles for 
one approach. We are wasting tons of man-hours here which would better be 
invested in other libraries. That's why I think it is a bad development. 

> Therefore: my absolutely top priority is to use a library
[..the consensus was to cut to:] that provides
> 	- native look and feel

If we are giving up on this, lets bin gtk2hs, HToolkit and all the other
toolkits out there and use wxWindows. If not, we will have write a binding
for Apple Carbon, use the Win32 library in GHC and (hopefully) gtk2hs to
cover the three major platforms. In the latter case, bin the rest. Of
course we can still have them around, but who would maintain them if 
there is no need for them. 

Your
> Priority 1 advises strongly against a GUI library supported by one
> person alone, no matter how talented.
As soon as one approach is taken, people will use it and thus it would be 
supported. The problem of fragile and out-of-date GUI libraries lies in the 
fact that nobody uses them and there is hence no incentive to support them.

> Priority 1 also argues in favour of a Haskell GUI library that is, in
> turn, built on top of a non-Haskell GUI library which is itself
> multi-platform, being actively developed, and likely to persist. We
> don't have enough effort to re-implement this stuff!  (As I understand
> it, this is one of the attractions of the Wx approach.)

wxWindows doesn't allow the use of native functions for bits of your
program to make it really look native. That's the criticisim. If the 
community can live with that, we can use wxWindows right away. In this case 
there is no need for another layer to which other libraries can bind since 
there is no need for other libraries. 

> An internal goal (irrelevant to Joe Programmer) is that the
> Haskell-GUI-library design should be high-level enough that it can be
> implemented on top of more than one underlying non-Haskell GUI library.
> That is a worthy goal, but the discussion I have seen has made me
> conclude that it is simply too difficult to meet.  Let's abandon it!

I agree with Wolfgang that the process (email list) is not very suitable.  
I think it's not too hard to find a subset which meets the two goals of the
Common GUI API mentioned above. Once it is in place, other libraries can
still exhibit it but I doubt that there is an incentive to write bindings
to other libraries.

To me the only sensible routes are: Either a Common GUI API as defined
above or wxWindows.

> This is a big issue: it's really holding up Haskell.

Sigh,
Axel.