Ever expanding TODO lists

There was a short discussion on the wxhaskell-users list yesterday about a fairly long outstanding wxHaskell bug: the fact that you cannot restart a wxHaskell GUI from within GHCi.

This post is not about that bug, but about a comment from Eric Kow:

 people are actually quite understanding about things being done slowly if
 they have a clear idea where they're headed, ie. what's being prioritised,
 what's not; what things are blocked on, etc.

Eric is quite right, of course, so this post is a quick dump of my wxHaskell TODO list. Sadly, at the moment I seem to be the only person doing any wxHaskell core development (though I’d like to namecheck some great help from Brian Lewis on Cabalizing wxHaskell a couple of months back), so it is probably the wxHaskell TODO list. The list is in approximate priority order, although I reserve the right to change it unilaterally if I find I have an urgent need for something!

1. Update wxHaskell to work with GHC 6.12.1 once the next Haskell Platform is released (I don’t have the time to go putting together a complete platform myself from source, so I’ll wait on the Platform)
2. Finish the series on wxhNotepad. I see this as extremely important in helping wxHaskell beginners to get going. The next two posts are mostly finished, and you should see them soon.
3. Solve the problem (a consequence of Cabalization) that, at least on Mac and Windows, it is no longer possible to use wxHaskell at all in GHCi due to a dependency on libstdc++ (which exists only as a static library on Mac and Windows). This is really a GHC/GHCi bug, but we need to deal with the consequences.
4. Write improved documentation and/or blog articles on specific aspects of wxHaskell. Layout is a strong contender for more work.
5. Investigate why wxHaskell cannot be reloaded in GHCi. Actually, I have a pretty good idea what the problem is. The wxWidgets library uses C++ static constructors and destructors in a few key places. When wxHaskell returns, what it actually does is to return from wxApp::OnInit(). Unfortunately, on return from this function, some of the internal structures of wxWidgets are corrupted and this can only be resolved by ensuring that the static destructors are executed and that the static constructors are re-run. I believe that the solution will probably involve dynamically unloading the wxWidgets library and reloading it. Since this is something which is almost completely OS-dependent, it will require me immersing myself in arcane details of dynamic linking for Windows, Linux and Mac to get it working.
6. Get the Styled Text Control back into wxHaskell, but now as a separate (Cabal installable) module. This will act as a demonstration/tutorial for bringing any wxWidgets component which can be compiled as a separate library into wxHaskell
7. Look at the list of bugs – both in the buglist and those accumulated in wxhaskell-users
8. Write a guide to make it easier for others to contribute to wxHaskell. I’m well aware that the amount of effort I can contribute to the project is not really enough to keep it thriving, and I’d like to lower the barrier to entry.

I find it slightly sad that the Haskell community doesn’t really seem able to support even one full-featured GUI binding (from what I can see, Gtk2hs development is also very slow at the moment). It’s not very glamorous work, but I believe it is an important part of making Haskell useful to a wider range of people.