[Glade-users] adding custom widgets written with Gtkmm

[tristan.van.berkom at gmail.com (Tristan Van Berkom)]

On Sun, Sep 21, 2008 at 6:36 AM, Tristan Wibberley
<tristan at wibberley.org> wrote:
[...]
> glade is calling my init-function and my tests show that double init
> does not break in a simple case.
>
> glade is calling gtkmm___custom_object_mywidget_get_type
>
> glade is not calling gtkmm___custom_object_mywidget_new but instead it
> seems to be making the object in some other way that doesn't call the
> object's constructor so doesn't set the NO_WINDOW flag or any other
> necessary part.
>
> I've looked into this, and it looks like a gtkmm widget cannot be
> created with gtk_type_new, so I'm going to try writing a real gtk widget
> adhering to the requirements of a gtk widget including support for
> gtk_type_new, then make that widget have-a gtkmm custom widget which it
> will forward all signals to. Hopefully that will work. I'm not sure how
> to indicate that all signals should be forwarded but I'm hoping it can
> be done.

Ok,
   sounds like the logical thing you might try from the app programmers pov,
but its not livable as a long term solution - I think what we need to do from
glade is add a glade_widget_adaptor_construct_object (adaptor, GType type)
to allow the plugin module to do the g_object_new() for us - this way we
can offer the same routine from a support c++ module - allowing us to
create the widgets as c++ objects and just returning the wrapped GObject.

One problem I can see might be if the c++ object is somehow owner of
the GObject - we need to create the c++ object in a way that it will
die when the GObject dies (bu refcount), and not when it goes out of
scope in the plugin (probably just a matter of adding an extra ref ?)

Can you checkout glade3 from trunk ? I can add a backend
object-constructor-function
for your testing purposes, this part would be a sinch for me...

Cheers,
                        -Tristan