Re: [Gtk2hs-users] libglade bindings

[Axel S. <A....@ke...>]

On Thu, Nov 20, 2003 at 02:48:00AM +0000, Duncan Coutts wrote:
> Hi all,
> 
> I've been fiddling with libglade bindings. I've partially ported
> Manuel's gtk+hs libglade bindings to gtk2hs, and updated them to work
> with libglade 2.0.
> 
> libglade 2.0 is somewhat simpler that v1.0. For example all the *_init
> functions have been depreciated (it now does it automatically). There
> are quite a lot of functions we don't need, eg for adding libglade
> extensions. There's a plethora of signal connecting functions, where we
> only need one.
> 
> There are basically only 3 important functions, and perhaps only 2:
> 
>      1. glade_xml_new() (also glade_xml_new_from_buffer variant)
>      2. glade_xml_get_widget()
>      3. glade_xml_signal_connect ()
> 
> The last one is the most problematic but fortunately in also not
> strictly necessary. The problem is: what is the type of the signal
> handler? gtk+hs has some solution to this problem, but I wonder if it
> wouldn't be that bad to just ignore it since if you use
> glade_xml_get_widget, you can then set up a signal handler on the
> returned widget.

Yes, I think that is a good approach.

> 
> A straightforward binding for glade_xml_get_widget gives:
> xmlGetWidget :: GladeXML -> String -> IO (Maybe Widget)

It would be nice if we just had a function

loadResources :: FilePath -> IO ()

which inserts all top-level definitions of a libglade file into the table 
defined in

mogul/WidgetTable.hs

The you can use the functions in GetWidget to get the appropriate widget 
with the correct type.

> however then the user would have to manually downcast every time to get
> the appropriate widget type. What would be nicer would be to have:
> xmlGetWidget :: WidgetClass widget => GladeXML -> String -> IO (Maybe widget)
> 
> Where it does a safe glib downcast (returning Maybe) to the type at
> which you use it. So I could do:
> 
> Just (button :: Button) <- dialog1 `xmlGetWidget` "button1"
> 
> Can we do this with the existing gtk2hs infrastructure, or do we need to

Yes, it's all there. The first part of Hierarchy.chs contains all the 
up-cast functionality (with a check at runtime if it is a legal cast).

> The autoconnect stuff is never going to work. It works for C, where
> there is a simple mapping between function names and symbols in object
> files. Even if it did work it wouldn't be useful as it wouldn't match
> the Haskell style at all.
True.

The problem with the mogul stuff and the reason why I didn't push it 
further is the following: The libglade library builds a widget tree in 
memory given a name. With the mogul stuff you can create a widget with a 
name. The difference is with multiplicity: You can create two widget trees 
with the same name, but if you create two widgets with the same name 
(having the same type), you might get either one and they might have 
different types. I am open for a clean design here...

Axel.