Re: [Gtk2hs-devel] GObject Instrospection

[Axel S. <Axe...@en...>]

On Wed, 2008-07-09 at 21:41 -0300, Marco Túlio Gontijo e Silva wrote:
> Em Qua, 2008-07-09 às 22:34 +0200, Axel Simon escreveu:
> > Hi Marco,
> 
> Hi Axel.
> 
> > On Jul 9, 2008, at 22:12, Marco Túlio Gontijo e Silva wrote:
> > 
> > >
> > > 1) a completly auto-generated binding with full support to the GTK
> > > family and
> > > 2) a higher level library with this hand-written funcionality.
> > >
> > > I think this would be good for maintaining a full similar to C GTK
> > > binding, and keeping gtk2hs specific features splited.  The
> > > documentation of the low level would not need much of corrections from
> > > the C documentation, while the other one would have to be rewritten.
> > > Don't you think it worths?
> > 
> > I don't think that a "complete" wrapping around the C API is very  
> > useful as the challenge is mostly to determine what parameters mean.  
> > For instance, a pointer to a structure could be an input or an output  
> > and hence needs to be marshalled in, out or a ForeignPtr must be  
> > created.
> 
> This is for sure a big problem, but gobject introspection is written to
> avoid this kind of confusion.

It is true that this information is contained in the metadata. However,
there are certain design decisions that we've made to make the library
easier to use. That includes whether a type should be wrapped in a
newtype definition and be opaque to the user, the omission of certain
low-level APIs (some functions and signals in a widget are only useful
to the widget itself), to an additional abstraction layer (e.g. UTF-8 to
Unicode translation) or just plain re-implementation in Haskell (e.g.
ModelView.*). It is very difficult (or impossible) to implement such
layers on top of a low-level binding of the C functions without making
the C functions themselves unusable (i.e. too low-level).

We've had a long discussion about this before when the question was
raised what a standard GUI API should look like. There was a consensus
that one could distinguish between three API levels:

low-level: minimal wrapper around the C functions

mid-level: functions live in the IO Monad but the library makes certain
things easy so that you can't shoot yourself in the foot (memory
management); also some simple OO theme (set and get functions)

high-level: combinators to connect or construct GUI objects, information
flows via lazy channels or the like; examples are Fudgets. It's not
clear that this approach works in the large as it looks like there are
always tasks that cannot be done with a combinator library

> > An interface in the spirit of 1) is basically automatically  
> > generated by c2hs and hsc2hs which create foreign import declarations  
> > and marshalling functions from the more high-level (handwritten)  
> > Gtk2Hs source files. So in a sense, Gtk2Hs is already what you  
> > describe above!
> 
> I don't agree with that.  To use c2hs you need to have already written
> the haskell code.  The idea is to have a library without no haskell code
> written at all, which is completly useful, in a sense that the
> hand-written functions are only optional, and used only when it's much
> better to have something more pratical available.

We could use the introspection possibility in apiGen and I think Duncan
has thought about that. 

> I'll do some tests with gobject introspection and see how good can the
> generated code get, and then you see if it's a good option to integrate
> it with gtk2hs.

I might be good if you think of how you can incorporate the data gleamed
from introspection into apiGen. We could then think of ways to put the
code that cannot be generated automatically into some sort of 'exception
dictionary' and have apiGen generate all code before we build (rather
than us doing a manual merge).

One aspect that introspection cannot give us is versioning: We have
gathered a lot of #ifdefs in our code and added comments to let people
know what Gtk version they need to have. I don't think introspection can
give you that.

This could be an interesting long-term perspective. However, the build
system of Gtk2Hs is already quite complicated. Generating all Haskell
files automatically will make it even harder to Cabal to build it.

Axel.