[Glade-devel] Glade Binding Framework



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





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