Bottom of the list is: - functionality - native look and feel

What's "native look and feel" doing at the bottom of the list? IMHO "native look and feel" is a prerequisite for any Macintosh App that is going to be accepted by Joe Mac User. So if Joe Programmer wants Joe Mac User as one of his customers, he'd better go for native look and feel.

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 didn't reach that conclusion from the discussion. I still believe it's possible, I only reached the conclusion that a mailing list discussion doesn't work too well. The issues at hand are much simpler than the discussion about them.

Joe doesn't care. I think it'd be fine to pick *one* library (Wx, Motif, X11, Tk, whatever)

Wx at least tries to provide native look and feel (with limited success on Mac OS so far); we might just choose Wx and hope that the Wx folks will one day fix the deficiencies. A Haskell GUI lib based on any of the others would be next to irrelevant for Mac OS development (no native L&F, perhaps even a separate X11 installation required). So I'm still in favour of platform-specific backends; but I wouldn't protest too much if we opted for the Wx option after some more discussion. Cheers, Wolfgang

Simon Peyton-Jones wrote:

Next priorities are: - readily available to people who want to modify my source code

Mostly Joe Programmer wants someone who will fix the bugs he reports, he doesn't have the time or the inclination to modify the GUI library.

- available for more than one Haskell implementation

Joe Programmer probably doesn't care about this, because he only uses one. So long as it's available for the one he uses, he's happy. Of course, Joe Programmer and Jim Programmer use different compilers, so this remains a problem for the GUI library developer. But I think it's not really Joe's concern.

Bottom of the list is: - functionality - native look and feel

Without both of these, the thing won't be used at all... Joe Programmer will have a hard enough time convincing his boss to let him use Haskell already, without having to explain why the GUI "looks all weird".

Priority 1 advises strongly against a GUI library supported by one person alone, no matter how talented. As Joe Programmer, I'm very, very keen to use a library that is cherished, developed, and supported by many people. They may each do different tasks, but multi-party buy-in gives me confidence that it's not going to go away when (say) Daan or Krasimir gets hired by a Wall Street finance house.

Yes.

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.)

Yes. It also means you can retrain people more easily. For instance, I've used wxPython before, so when I use wxHaskell I at least understand what widgets are available, how they work, how wxWindows does layout and sizing and so on, even though the API is a bit different.

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! Joe doesn't care. I think it'd be fine to pick *one* library (Wx, Motif, X11, Tk, whatever) and allow that to influence the design of what gets exposed to the Haskell programmer. Apart from anything else, it makes life easier by taking a lot of design decisions (for better or worse) out of our hands. Once an underlying library is chosen, many things get fixed.

Speaking as someone who has built a GUI library for Python that runs on both the C++ library Qt and Java's Swing (with Jython), I agree completely! Accommodating multiple underlying GUI toolkits is difficult work, and is best attempted only when you have a significant number of people willing to (actively) help.

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

I couldn't agree more. Btw, I understand both wxHaskell and HToolkit are early in development, but I should mention that Joe Programmer needs grid and tree controls! This is off topic for the gui list, but I feel I should mention that two other things that hold me back from trying to convince someone at work to let me use Haskell are lack of SQL drivers for MSSQL and Oracle, and the fact that sockets don't seem to work right in GHC on Windows, especially with threads. Bryn