[GUI] ByeDemo

[Daan Leijen]

> >  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
>
>