2 Obtaining wxWidgets

Note that wxHaskell is currently between wxWidgets 2.8 and the development 2.9 release, so it pays well to ensure new code will work with both versions. It is possible to safely co-habit two version of wxWidgets. When you do wxHaskell will build against whichever version is returned by wxconfig --version, on Linux you can change which version you build wxHaskell against by follow steps similar to this (this should be easier):

3 Building and testing wxHaskell

Firstly, see Source Release, however it is recommended that you do the following, instead of following the instructions there to build each component:

Use Cabal-dev to isolate your development code from stable wxHaskell packages you may have obtained from Hackage.
You can then install your development version of wxHaskell into a separate Cabal-devpackage database (which will be under ./cabal-dev/packages-7.0.3.conf/).
To do this enter the root wxHaskell directory (the one you obtained from the current repository) and enter the following:

4 Wrapping new wxWidgets functionality

4.1 Purpose of files which will need to be updated

Although the specific modifications required depends on the complexity of the wxWidgets functionality you are wrapping, this list serves to document the relationship between the files and what purpose they serve.

./wx/src/Graphics/UI/WX/Controls.hs

'High' level Haskell wrapper. You place constructors which are property-aware here. In most respects this is straightforward except that you need to work out what instances are appropriate to a your new functionality. You may want to look here for some more information about implementing Attribute instances.

./wxcore/src/include/wxc.h

This creates the correct type witnesses to map the class Hierarchy.

./wxcore/src/include/wxc_glue.h

This is basically where you need to put the declarations for C++ method wrappers.

./wxcore/src/haskell/Graphics/UI/WXCore/Events.hs

Your Haskell event handler code goes here. You need one function which reacts to events, which accepts an event handler as a parameter and a function which will fetch your event handler (you need this mostly in case you want to hook a further event handler which doesn't kill the one already present).

./wxc/src/cpp/XXX.cpp

Implementations of the wrappers. The old eljXXX naming convention for these files really isn't necessary any more. I'd suggest calling the implementation mynewfunctionality.cpp or something like that.

./wxc/src/cpp/eljrc.cpp

Constructs functions for getting control pointers out of window hierarchies created from XRC files.

./wxc/src/cpp/eljevent.cpp

Wrap up event values as functions. I tend to do this instead.

./wxc/src/cpp/defs.cpp

Another way of wrapping up event values as functions. (Jeremy: I don't tend to do this, and I don't think anyone has for years.).

./wxc/wxc.cabal

Ensure you add mynewfunctionality.cpp to c-sources in ./wxcore/wxcore.cabal