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. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Gtk2hs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
