Re: Reverse-wrapping gtkmm widgets to gtk+ (for glade3)



On Fri, 2006-11-17 at 15:14 +0100, Murray Cumming wrote:
> > Having looked at Glade3 and its custom widget support I would very much
> > like to use it.
> 
> Can you point us at any documentation on this API. For instance, how
> would someone go about making custom GTK+ widgets available for use in
> Glade.

http://glade.gnome.org/docs/index.html

The first chapter is about adding your custom widgets to glade. It is
actually very simple if your widgets only use properties for settings,
in that case you only need to create an xml file (catalog) with
information about the widgets (nothing more than a name, really) and
the .so which must be loaded.

Of course for runtime loading with libglade the widgets in the .so need
to be known with Glib before they can be used. This can be done with an
init function which get_type()'s all the widgets.

> I suspect that something might be possible, though the gtkmm widget
> would probably need to register its own GType (not too difficult), and
> to get the full benefit of Glade we would need to define some GObject
> properties for the gtkmm widget.

Indeed, registering your own GType is not too difficult (adding
Glib::OBjectBase("mywidget") to the constructor does it. However, for
Gtkmm custom widgets libglade still instantiates a widget of the parent
type. I assume the reason for this is that Gtkmm does not provide a full
Gtk+ gobj for my custom widgets; which is understandable, but very
inconvenient when interacting with C-only libraries such as
glade/libglade.

> > If this is not possible at the moment is any work on this being done to
> > get it in Gtkmm? This is especially important because in Glade3 the
> > custom widget facility is marked deprecated, only for Gtkmm widgets
> > there is no alternative since it would seem we cannot let glade/libglade
> > to instantiate Gtkmm custom widgets!
> 
> Don't forget get_widget_derived(). It does most of what you probably
> want - you just won't see the derived widget's specific appearance in
> Glade.

Ah, yes that is very true if the widgets only differ a bit from standard
widgets. For widgets that are derived from a drawingarea it becomes a
bit more frustrating as the appearance in glade will be a lot of grey,
empty frames.

Furthermore your must still exactly know in your application which
widgets in the glade file resemble your own custom widget types. At the
moment I'm working on an application which dynamically loads glade files
and automatically connects the found widgets to a backend with update
functions. We only know their names, types and function at runtime. At
the moment when I see a Gtk::Label in the glade file, it could actually
be a Gtk::Label, or perhaps a custom derived type of a Gtk::Label. With
only get_widget_derived() I cannot know for sure; the custom widget type
information needs to be in the glade file to get it fully working. With
the (in glade3) deprecated custom widget type this is working, but as it
is deprecated another method of equal capabilities is required. The new
custom widget handling in glade3 looks as if it can provide all of this,
and more (finally we have the possibility to have custom widgets
functional inside glade). But at the moment only for C-Gtk widgets, not
Gtkmm without a _lot_ of glue code...

Brgds,
  Alexander Brinkman.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]