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 [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel
