Some time ago, I wrote a GUI for a large OCaml project in C++ using WxWidgets, linked to OCaml in a single executable. It was hard and slow to write and crashed all over the place.
So I’ve redone it in a particularly low-tech way. Consider the following:
- A GUI layer in pure Python, using the wxPython library
- A GUI library written in pure OCaml
We start the two in separate processes, and have them talk via a socket. Sounds horrible – works fine.
Advantages of this as a long-term approach to the building of a proper OCaml GUI library:
- Pure. No FFI involved
- Wxwidgets is very good. It’s a whole platform and a mature one
- Cross-platform by default. Native appearance on Windows, Unix, OS X
- Effort required by OCaml community lower than for any other option
- Build single executables for release with py2exe and py2app
- Write OCaml interfaces to hundreds of python libraries
Disadvantages (please add more in the comments!)
- Python and OCaml processes can fail independently
- Might need to work on getting executable sizes down
- Asynchronous event loops need care: work required to ensure mouse events don’t get out of sync etc – but this is fairly easy to overcome.
Here is a screenshot of our rendering engine using this approach on the Mac, on Windows and under Ubuntu.
I don’t have the time to write a generic OCaml / wxpython library at the moment, so I’m just going to stick with my special purpose implementation in our software for now.
In Part Two, I’ll release the basic libraries:
- mltalk.py, pytalk.ml (Establishing a connection between Ocaml and Python processes)
- camlpy.ml pycaml.py (Marshalling and Unmarshalling Ocaml and Python data)
- Wxgui.ml (Event polling and synchronous events)
- main.ml, main.py (Main programs)
- Scripts for py2exe and py2app
Hopefully someone will have the time to build a proper library from this example.