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