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

[Murray Cumming <murrayc murrayc com>]

On Fri, 2006-11-17 at 17:50 +0100, Alexander Brinkman wrote:
> 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;

It should if you have used Glib::OBjectBase("mywidget") and that init
function is being called to register that type. However, I'm not sure
how we would register that type easily in the init function without
instantiating the widget.

>  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.
-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com