Sven Panne <[EMAIL PROTECTED]> wrote,
> "Manuel M. T. Chakravarty" wrote:
> > [...] That is quite important as GTK+ requires the programmer to
> > directly access GDK for things like using alternative input
> > devices (eg, graphic tablets) and using rendering libraries
> > like Sven's OpenGL binding.
>
> OK, OK, the discreet hint has been understood... :-) If the weather
> allows it, I'll try to assemble a pre-release HOpenGL this weekend.
> It's not complete, but I'd like to get some feedback.
Great :-)
In exchange, I promise that I make the GTK+ functionality
needed for HOpenGL a high priority.
> Another downside
> is that relatively new versions of GHC and Green Card will be needed
> to compile it.
Living on the edge can be fun and it is always nice to have
a good excuse for updating ones software installation ;-)
> Regarding the GTK+/OpenGL-glue: It seems that GtkGLArea is still
> actively maintained and more powerful than gtkGL, but I don't have
> much experience with either of them. Comments or suggestions are
> highly welcome.
Judging from the GTK+ mailing list, GtkGLArea definitely
seems to be the more active one - a good reason to use it if
there are not any strong technical reasons against it.
> > At the moment, I am implementing a C header file parser to
> > automatically ensure consistency of enumeration types etc
> > between the original GTK+ headers and the Haskell binding. [...]
>
> What's wrong with using Green Card? Its %enum generates the desired
> mappings automatically and consistently. AFAIK, this type safety is
> something even IDL compilers don't do for you. E.g. I have an OpenGL IDL
> lying around here with which it's no problem passing a matrix mode as a
> texture name because almost everything is mapped to Int. :-P
> But I'd like to be proved wrong...
When I started, I of course thought about using Green Card
or HDirect. I didn't use Green Card, because HDirect seems
to be positioned as its successor (and I don't know if in
the long run, both will be supported). I didn't use HDirect
because (a) it is still quite "beta" and (b) I think it would
be an overkill.
Re (b): Most of the time that I put into the binding so far
was spent on design of the Haskell API and its mapping to
the C API. Writing the marshaling code etc was quite
painless and that's the only place where HDirect would have
helped. (The situation may be different for other
libraries, though.) What I really like is the new FFI! I
definitely think, it should be considered for inclusion in
the Haskell standard. (How about, Haskell 2k = Haskell 98 +
FFI? ;-)
However, I found that there is a certain type of material in
the binding code that, I think, I can generate from the C
header file. Therefore, I am currently implementing a C
header file parser. BTW a nice experience in itself...do
you know what
const struct bla {int y;} typedef foo (int x),
bar (char z);
declares?
Regarding HDirect, I think, its time comes when we want to
have CORBA support for using Gnome from Haskell.
Cheers,
Manuel
