Those who follow the wxHaskell developer or users lists will know that over the last few months there has been a flurry of activity on wxHaskell, spurred on by Dave Tapley. I wanted to summarise what has been happening, and what stands in the way of a release supporting wxWidgets 2.9
<blatent-plug>Dave is working on wxHaskell with the agreement of his employer, Mentics Inc. I encourage any readers who have the opportunity to place business in Mentics’ direction to do so in appreciation of this generous donation of time and talent to the Haskell community.</blatent-plug>
Why wxWidgets 2.9?
Most Linux distributions currently supply wxWidgets 2.8.x libraries from their packaging systems, and Windows has the pre-built and readily installable wxPack containing wxWidgets 2.8.12, so why are we moving to an unstable release of wxWidgets?
There are many reasons, but two stand out in particular:
- It is the future. wxWidgets 3.0 will be released from the 2.9 line, and provides major improvements. These include:
- Much improved Unicode support.
- Lots of new controls: ribbon bars, wxPropertyGrid, wxWebView, wxTreeListCtrl, wxRichToolTip, wxRichMessageDialog. Together, these simplify the creation of GUIs with a ‘modern’ look and feel.
- The stc library (used by StyledTextControl) is now part of the main library build (as is SVG, which I would like to wrap for wxHaskell in the near future).
- Support for 64bit OS X builds, which we have been unable to support on wxHaskell due to underlying lack of support in wxWidgets.
- We need to clean up some legacy ‘cruft’ in the code. Daan originally wrote wxHaskell for wxWidgets 2.4.x, and things have moved forward a long way since then. This is an opportunity to remove deprecated functions and offer cleaner APIs.
What is changing?
The changes listed exist today in Dave’s development repository at DarcsDen, and will be mainlined in our master repository at code.haskell.org starting the coming weekend.
- Newly wrapped classes
- PropertyGrid, related helper types and sample code (Dave Tapley)
- ListView (Dave Tapley)
- Reinstated features
- StyledTextCtrl (Dave Tapley)
- OpenGL (Me)
- Ability to use wxHaskell in GHCi (Dave Tapley)
- Build system improvements
- Some old Eiffel legacy code in the build system has been removed. Everything is now either C++ or Haskell (Eric Kow).
- The C wrapper for wxWidgets has been moved into a separate project, wxC and built as a shared library (Dave Tapley).
- Work to support OS X Lion (Eric and Alessandro Vermulen).
- A Haskell native implementation of wx-config for use on Windows platforms. We are not sure if we will use this as yet – it is experimental (Eric).
- Bugfixes and ‘build experience’ contributions from all of the above and several others , including Shelarcy, Maciek Makowski, Henning Thielemann, Peter Simons.
What is left to do before there is a release to Hackage?
Quite a bit!
The code in Dave’s repo is reasonably well tested on Linux (Ubuntu), but has currently received insufficient love on Windows or Mac. We will need it to work reliably on all three platforms before it can be released.
I think that the main blocker right now is probably determining the correct configuration for a Windows build. We have a couple of options here. We could develop Eric’s Haskell wx-config replacement so that it has been tested for a good subset of all possible wxWidgets build configurations, or we could fix wx-config-win to the same end. This has raised some philosophical questions on ‘Open Source and community’ which I am thinking of blogging on separately.
Most of all, when we have candidate builds ready, I hope that wxHaskell users will help out by trying to install the new version on as many machines as possible, so that we can be sure that we have everything working.
A rock to wind a piece of string around 
Awesome!
You know, I’ve always wanted to show some appreciation to you and the wxHaskell team. Why don’t you have a Flattr-button?
Hiya,
I’m glad that you are pushing wxhaskell forward, but, unfortunately, we moved away from Haskell although still interested for wx.
That’s why I’m curious if “The C wrapper for wxWidgets has been moved into a separate project, wxC and built as a shared library” could be useful for developers of non-Haskell bindings as well (in our case we think about D)?
Sincerely,
Gour
This is actually the subject of some debate within the wxHaskell community, and I am in the process of writing a separate blog entry covering some of the issues.
wxC is certainly a reasonable basis for a wxWidgets wrapper for other languages (it exposes a straightforward C interface and builds as a DLL/.so/.dylib). The build system is presently rather Haskell-centric, which might put off other language communities, but if you did a ‘cabal install wxc’, you would get a DLL you could use with most any other language.
Similarly, if you can read plain C header files, you should be able to use the wxC library (I’m no D expert, but everything I have read suggest that D can do this quite easily).
If there was enough interest from Non-Haskellers in joint development and maintenance of wxC, then I think we would be comfortable moving to a more, err, inclusive build system, but while the main contribution comes from Haskellers it is harder to justify such a move.
Some time back, Eric took control of the moribund wxC project at Sourceforge. We could use this as the basis for such a project.
That would be nice.
I fully agree.
That’s to be expected now…/p>
It is a pity…On Nov 22nd last year, I did ask on wx-users about possible project to make it easier for bindings developers (see “help for language bindings developers” thread”) and Vadim Zeitlin replied:
I am not aware of such a plan. IMHO it’s not very realistic and I think
the best bet to make writing bindings easier in practice would be to have a
well-maintained and working wxC project. I also think that SWIG is the best
bet to make it work in practice but there could be other approaches. In any
case the most important thing would be to find someone motivated enough to
work on it.
So, I believe that we both would like to propagate wxWidgets library more and it would be nice to work together with all the bindings author to make wx available for more languages more easily.
I’ve also quoted your message on the D list and one user wrote the following: “i think wxC is a very special ‘binding’ that can work as a basic layer for multiple language ‘bindings’.
As such the optimal solution would be if there is only one wxC that is part of wxWidgets itself.
The natural choice for the build system is then wxWidgets own build system. So it would be more easy to keep it in sync with WxWidgets. Developers of all language bindings can unite their forces on it.
Maybe even wxWidgets core developers would like to care for keeping it in sync if it is not to much work.
Sharing wxWidgets build system, wxC can be build on the same target platforms as wxWidgets.”
What do you think?
I forgot to say that it would be nice if some of wxhaskell devs could post to the wx-users list (it’s available via gmane)…
Sincerely,
Gour