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.