[wxhaskell-users] Haskell Platform roadmap?

[Jeremy O'D. <jer...@gm...>]

Hi all,

This is a call for help. There's been some discussion both on this list and
on the cafe about getting a GUI into Haskell Platform.

The formal requirement is that inclusion needs to be supported by at least
one library maintainer, and from a practical perspective it should be
something which builds and works well on all supported platforms, i.e.
Linux, Windows and Mac, and should have a team of maintainers who are able
to maintain the code over a long term basis.

While there have been some fantastic contributions to wxHaskell over the
past years from any people, the reality is that most of the work gets done
by me, and some may have noticed that I don't have a lot of time - certainly
nothing like enough to commit to inclusion in Haskell Platform.

The call for help is this: can we get together a team which would be able to
field enough effort to make a submission for Haskell Platform realistic? I
believe that such a team would look something like the following:


   - Project lead, release co-ordinator and mentor to others. That will be
   me then.
   - Target leads for Linux, Mac and Windows. Responsible for building tip
   code for their platforms and providing fixes when it breaks. In the case of
   Mac and Linux, extra points if you can make things work using the platform
   built-in wxWidgets.
   - A number of specific functional areas to be addressed:
      - Fix the long-standing bug preventing GHCi use of wxHaskell. In my
      opinion, this is best addressed by factoring the C wrapper for
wxHaskell (we
      call it wxC) into a separate library which is built as a dynamically
      loadable library. I know, in principle, how to do this for Windows and
      Linux, but would need help for Mac. Anyone who wants to help should know
      that this involves lots of revolting work with linkers, and is especially
      suitable for masochists. That's probably me as well.
      - Make it easier to wrap some of the optional wxWidgets libraries.
      This requires work on wxDirect. This is probably the easiest
area to work on
      as wxDirect is a self-contained executable, and is small and
fairly simple
      to understand.
      - Using the above, wrap some of the optional libraries. STC should be
      reinstated in wxHaskell now (it's part of the core in wxWidgets 2.9), but
      there are many others. OpenGL canvas, AUI and the media framework look
      particularly interesting.
      - Consider a pure Haskell replacement for wx-config, at least on
      Windows, but potentially on all targets. We currently bundle a 3rd party
      wx-config replacement for Windows, but it doesn't work very well on
      wxWidgets 2.9.
      - Extend Graphics.UI.WX so that more of the core functionality has
      high-level wrappers, e.g. for Grid, List boxes etc. I would love
to see an
      FRP wrapper around parts of wxHaskell, and think we could
reinstate one or
      more of the FRP libraries, for example. Making GUI programming
less like C
      programming would do a lot to promote Haskell GUI development, but it
      requires much better Haskell-fu than I have to offer.
   - Go back through the list of bugs and feature requests and fix as many
   as possible. This is an easy starting point for a new wxHaskell contributor.
   - Improve documentation. While wxHaskell is pretty good, it could
   definitely be improved. In particular, I think we should consider finding a
   way to generate better documentation for the wxC wrapper functions, which
   currently only include type information.

There's probably a lot more to do, and I welcome comments and suggestions. I
welcome offers of help even more, and estimate that getting into HP requires
a core team of 6-8 people who can commit to a few hours per week for at
least a year. This is a huge ask, but the outcome would be that wxHaskell
could become part of the Haskell Platform, and would likely be much more
widely used.

What do you think?

Best regards
Jeremy