[GUI] GUI meeting at ICFP?

[Bryn Keller]

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