[Glade-devel] Glade Binding Framework

[murrayc at murrayc.com (Murray Cumming)]

On Sat, 2007-03-24 at 11:46 -0400, Tristan Van Berkom wrote:
> On Sat, 2007-03-24 at 12:08 +0100, Murray Cumming wrote:
> [...]
> > > Shouldn't we just provide the class definitions statically, so that
> > > developers can subclass in the way it's usually done in most languages?
> >
> > Yes, C++ cannot declare classes at runtime. And I wouldn't want it to.
> I dont think that declaring C++ classes at runtime is the requirement
> here - rather declaring GObject subclasses at runtime is what is needed.

We can do that.

And it's possible in gtkmm, by providing a GType name explicitly to the
Glib::ObjectBase base constructor. This is how we implement custom
GtkTreeModels and custom GtkCellRenderers.

> If the GObject derived in a C++ plugin is not a proper GObject
> (i.e. if it is only some kind of C++ synonym of a GObject), then
> I dont see how the C-only core library can call methods on that
> object.
>
> Well I suppose not all hope is lost - C++ plugins could be made
> to use the xml catalog to furnish proper "C stub" entry points
> to the C++ binary - if the gladeui core also has language bindings
> for C++ then the C++ plugin can use those bindings to access the
> core... its just a little less elegant than having the ultimate
> "C++ object == GObject object".
>
> There is also the problem of communicating the GType of the
> actual C++ widget that is being integrated... surely a C++
> derived widget has a GType in the type system and can communicate
> that to the core using some kind of C stub _get_type() proxy ?

-- 
Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com