Re: [Gtk2hs-users] [Announce] haskell-gi

[Inaki G. E. <ga...@gm...>]

Hi Axel,

Thanks for the reply.

On Sat, 2013-06-22 at 09:32 +0200, Axel Simon wrote:
> that's very interesting to see. It seems to me that the long-term
> future of Gtk2Hs should probably embrace auto generating code using
> introspection more.
Glad to hear this. For the moment I am concentrating on generating
bindings for gtk, since it is complex enough and "canonical" enough that
it seems like a good test of haskell-gi. But given that we already have
good bindings for gtk itself, in the short term I see the value of
haskell-gi more in generating bindings for all the other stuff that has
introspection data. For instance, I have 184 installed typelibs
(introspection files for an installed lib) in my system. Even if just a
few of these are interesting it would still be nice to be able to access
them from Haskell code automatically, and hopefully the current code
should already be useful for many of these.

In the long term, it would certainly be nice to have something as good
as gtk2hs, but there's still some work left to get to that point.

> I think was is needed, in particular with respect to documentation, is
> a way to merge in hand-written stuff into the generated code. This
> could be specific documentation or a replacement for certain function
> etc. The most generic approach would be some sort of (XML?) document
> that is read in when generating the code.
> 
> An alternative: Duncan Coutts once implemented this generator that
> created bindings from some XML description. It annotated each function
> with a hash code that was computed from the auto-generated code. If
> the Gtk2Hs maintainer changes the function by hand but the hash code
> of the generated function stayed the same, the generated would simply
> retain the modified version. 
> 
> There are certain things that are completely written by hand, so these
> always need to be kept alongside the generated code. Examples are the
> TreeView models.
Thanks! This is a very good point, and something I forgot to mention in
the email. Some sort of override mechanism is needed, as you say. So far
I have managed by just blacklisting some troublesome functions by hand,
but a more systematic mechanism would be nice to have. Other language
bindings seem to have separate binding files, but the idea of editing
the generated code in place is attractive, I will take a look to see how
the generator you mention is implemented.

Thanks,
Iñaki

> 
> My 2p,
> Axel
> 
> On 21.06.2013, at 23:16, Inaki Garcia Etxebarria <ga...@gm...> wrote:
> 
> > Dear all,
> > 
> > For the last few weeks, as an exercise in learning Haskell better, I
> > have been playing around with haskell-gi, adding support for a bunch of
> > features. I based my work on the versions started by Will Thompson,
> > found in
> > https://gitorious.org/haskell-gi
> > and
> > http://git.rhydd.org/?p=haskell-gi;a=summary
> > 
> > Thanks to the excellent foundations there, and with a bit of work, I
> > think that the code is now reaching a stage that it may start to be
> > useful in actually generating bindings (at least for adventurous
> > folks :) ), hence this message. You can find my changes at
> > https://github.com/garetxe/haskell-gi
> > 
> > I tried to model the generated API on gtk2hs as much as possible,
> > although there are some divergences here and there. You can view some
> > examples of the generated code for the gtk3 stack at
> > http://cern.ch/inaki/haskell-gi
> > (Some example of actual usage of the bindings is given below)
> > 
> > What works:
> > -----------
> > + Typeclasses for modeling the GObject hierarchy, so if you have a
> > GtkButton "button" and want to pass it to a function expecting a
> > GtkWidget it will work without casting (see below for examples).
> > + Signals.
> > + Proper reference counting for GObjects and boxed structs/unions,
> > including automatic handling of ownership transfer on function
> > calls/returns.
> > + Automatic conversion between C types and Haskell types. (So, for
> > example, GLists are converted to ordinary Haskell lists.)
> > + GError handling, by throwing exceptions. Same notation as in gtk2hs,
> > with the addition of a type-specific (catch/handle)GErrorJustDomain,
> > named (catch/handle)DBusError, for instance.
> > + Setting/getting GObject properties. A nice feature is that the
> > readable/writable/constructOnly constraint are enforced at compile time,
> > so if you try to write a read-only properly you will get a (hopefully
> > clear) compile time error.
> > + "new" notation for constructing GObjects (see example of usage below,
> > feels nice to use).
> > 
> > What doesn't:
> > -------------
> > + GHash type elements are not converted to native Haskell types yet.
> > + GVariant and GHash valued properties are not yet supported.
> > + Struct/union field accessors (I will probably tackle this next).
> > + Structs/unions which are not boxed.
> > + Callbacks.
> > + Documentation. This is a big one, not sure what to do here. Since the
> > generated API is automatically translated from C, the C API
> > documentation is pretty useful already if one squints, but maybe we can
> > do better (perhaps reusing the gtk2hs documentation when it applies?).
> > Documentation for methods etc. is included in the introspection data,
> > but it is generally written with the C API in mind. Suggestions?
> > + Other things I am probably forgetting right now.
> > 
> > The generated code has not been battle tested yet, beyond some very
> > simple toy examples (see test/testGtk.hs in the git repo). If someone
> > finds it interesting and wants to take it for a spin, any comments about
> > the experience/suggestions would be very welcome. Or if anyone feels
> > like implementing any of the features above I would be glad to assist.
> > 
> > Well, I hope that someone finds this useful. It is being a good learning
> > experience anyway :) I will keep on implementing some of the points
> > above as time allows.
> > 
> > Any comments are very welcome!
> > 
> > Cheers,
> > Iñaki
> > 
> > Here's a not completely trivial example of use of the API, so you get an
> > idea of the flavor:
> > 
> > --------------
> > 
> > import GI.Gtk hiding (main)
> > import qualified GI.Gtk as Gtk
> > 
> > import GI.Utils.Attributes
> > import GI.Utils.Properties (new)
> > 
> > import System.Environment (getProgName, getArgs)
> > import Data.ByteString.Char8 (unpack)
> > import Control.Applicative ((<$>))
> > 
> > main = do
> >  args <- getArgs
> >  progName <- getProgName
> >  _ <- Gtk.init (progName : args)
> > 
> >  win <- new Window [windowType := WindowTypeToplevel]
> >  onWidgetDestroy win mainQuit
> > 
> >  grid <- new Grid [orientableOrientation := OrientationVertical,
> >                    gridRowSpacing := 5]
> >  set win [containerChild := grid]
> > 
> >  button <- new Button [buttonLabel := "Click me!",
> >                        widgetMargin := 5]
> >  onButtonClicked button $ set button [widgetSensitive := False,
> >                                       buttonLabel := "Hello, world!"]
> >  containerAdd grid button
> > 
> >  fileChooser <- new FileChooserButton
> >                 [fileChooserButtonTitle := "Please choose a file",
> >                  fileChooserShowHidden := True]
> > 
> >  onFileChooserButtonFileSet fileChooser $ do
> >         selectedFile <- unpack <$> fileChooserGetFilename fileChooser
> >         message <- new MessageDialog
> >                    [windowTransientFor := win,
> >                     messageDialogButtons := ButtonsTypeOk,
> >                     messageDialogText := "You selected <i>"
> >                                           ++ selectedFile ++ "</i>",
> >                     messageDialogUseMarkup := True]
> >         dialogRun message
> >         widgetDestroy message
> > 
> >  containerAdd grid fileChooser
> > 
> >  widgetShowAll win
> > 
> >  Gtk.main
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> > 
> > Build for Windows Store.
> > 
> > http://p.sf.net/sfu/windows-dev2dev
> > _______________________________________________
> > Gtk2hs-users mailing list
> > Gtk...@li...
> > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users
>