A Proper GUI for OCaml (Part One)
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.
March 19th, 2008 at 4:35 pm
Very interesting! I think OCaml is a wonderful language, but it still lacks in a decent GUI toolkit, something as complete as QT, for example.
Some time ago I had the idea to link two executables together via socket communication, but I had no more spare time to develop it. I’m glad someone successfully realized a similar project.
At what level the communication takes place? In my original design a GUI entirely written using QT (C++, Python) talks with an underling OCaml process using DBus. QT actually wraps DBus messages into its signal/slot paradigm, so it should be not too difficult to create the link, since a binding for DBus is available for OCaml.
In this design no “mouse event” are passed between the two processes, but only high level “signals” have to be passed. In my idea this should simplify the design a lot.