I have been thinkering with the wxWindows library and made a small Haskell binding to it that just supports this example. It was an interesting exercise since the wxWindows library is a large object-oriented C++ library. (but very portable, well supported, efficient and with lots of super widgets, like an openGL canvas and a HTML renderer)
It is really interesting. How did you bind the library? Could you make a tarball of the binding, the example and a makefile? It could be used as an "Haskell->C++" tutorial.
(warning: rather detailed and long answer...) I have only done it for windows yet, both with mingw32 and visual C++. Funny thing: the final (stripped) DLL with mingw32 was 2.8mb, while the visual C++ DLL (with the same functionality) was just 640kb :-). In the end, I couldn't link it directly with a haskell application due to the difference between the C++ and plain C runtimes, so I have made dynamic link library (.dll) of the C++ code. This code exposes a plain C interface (with "extern "C""). This interface is basically a flat C view on the object oriented wxWindows library. This DLL is accessed with foreign imports from Haskell. Call backs are dynamically created using dynamic exports ("wrapper"). Actually, the hardest part was to make sure that the resource files (.rc) were properly linked in the DLL, as we don't want to deal with those from Haskell. I don't know yet if this approach also works for unix's (.so files?) or MacOSX, but there probably is a way to do this. In the end, it is good enough if there is some way of wrapping the C++ code into a C library. Maybe someone on this list can tell me more about how this could work on unix like platforms??? The part that is most challenging, and which I am still working on, is trying to fit the event model of wxWindows into a reasonable model for Haskell (or other languages for that matter). Somehow, I need to create "universal" widget objects that are programmable from outside (i.e. Haskell) but normally, one derives application specific objects for each widget in wxWindows. There are mechanisms for more dynamic applications (like I want) but I am still trying to figure out the right way to do it. I think this is basically a universal problem when trying to interface to foreign object oriented (or any other paradigm for that matter) with a functional language. It is not just the marshalling and calling conventions, but the programming model makes a huge difference. Years ago, when designing H/Direct we automated the marshalling process, but it seems that that is just a small part of the problem. Trying to fit into an entirely different programming model is very hard. For an extreme example, I think that there is no reasonable way of interfacing to the Java Swing model. Fortunately, it seems that the wxWindows library is much more flexible, and up till now, I haven't encountered any hard problems. Maybe this is actually the right way to go for a Haskell GUI library -- let others do the hard work of maintaining a rich,portable gui library, and we just have to do the hard work of interfacing to c++ once. All the best, Daan.
Vincenzo
-- First they ignore you, then they laugh at you, then they fight you, then you win. [Gandhi]
_______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui