[Haskell-cafe] My experience setting up Haskell up for GUI development

[Jeremy O'Donoghue]

Ben Arnold wrote:
> WxHaskell was a little trickier but more successful. There didn't 
> appear to be any installation instructions on the website, but it did 
> imply that I needed to install wxWidgets first. I did that, and made 
> sure the paths didn't have spaces in them (yawn). And after restarting 
> the PC eventually I got a working Hello World dialogue box.
>
> Which is nice, except that when I call "main" twice in succession from 
> GHCi, ghc.exe crashes. So I have no confidence in the wxHaskell 
> libraries either. I don't want to invest time in programming with 
> libraries that perform illegal operations on my operating system.
This is a known wxHaskell problem, and is a consequence of changes in 
the underlying design of wxWidgets since wxHaskell was designed.

The basic problem is that wxWidgets, since around wxWidgets 2.5, uses 
C++ static constructors and destructors to initialize and destroy some 
internal data structures. Unfortunately, on Windows, the only way to 
make these run is to unload the wxWidgets DLL when main terminates, and 
this is something we do not currently do (I'm working on it, but it is 
not trivial, and I have little time to work on the problem, so progress 
is slower than I would like).

If this functionality is essential to you, I can only suggest using 
wxHaskell 0.9.4 with wxWidgets 2.4.2. This older version of wxWidgets 
does not use static constructors/destructors, and can be used to execute 
main more than once. This older revision is three years old now, and 
will require you to use GHC 6.4.

In terms of an 'expert' reference - wxHaskell or GtkHs are the only 
reasonably maintained GUI options for Haskell. GtkHs has a larger team 
of contributors, but both are capable of producing complex and stable 
GUI applications - I can certainly vouch for wxHaskell in this respect 
(and in respect of speed of development), and the reason I work on it is 
precisely because I didn't want to see such a superb piece of software 
rot through lack of attention.

However, both projects rely on fairly small volunteer teams working on 
their spare time out of love (or something like it...), and I think it's 
fair to say that both teams are some way from matching the ease of 
developing and deploying of, say, C# or Java.

Regards
Jeremy O'Donoghue