On Wed, 2008-11-26 at 03:00 +0200, Cristi P wrote: > I struggled some time ago with doing object inheritance at more than > one level, like: > Glib::Object -> MyObjectA (w/ some properties for example) -> > MyObjectB (w/ additional properties and/or overriden [virtual] > functions) > While the gtkmm says about using "inheritance" I couldn't solve the > problem the way I expect from a C++ library. So, unless I'm mistaken > somewhere, it *almost* is impossible. > At that time I did some hard stuff to overcome that problem (with > implications on how you write your objects) but now I'm getting in > even bigger problems, when > instead of starting from Glib::Object I start from some other C++ > wrapper, like, for example, > Clutter::Group -> MyObjectA -> MyObjectB > > This is really annoying since I want to use C++ w/ the various > wrappers in more then a simplistic GUI wrapper and with one level of > inheritance :-( > > So far the problems that I think I saw: > a) it seems that the glibmm::object* source files (or at least some > ObjectBase constructors) are assuming derived objects are mostly C++ > wrappers or one level deeper > b) (from memory) saw some strange things about declaring the wrapper's > type as being the C actual type instead of the just created type ? > I think there was also a comment like "allow g_peek_class..." to > work !? > c) wrappers around methods want to "peek" at the original C object to > call some functions for example, and are assuming current object has > its parent type the C object, which, in case it runs on > object MyObjectB, it is a wrong assumption.
I don't really understand what your problem is. Could you be more specific on what the actual problem is when you have a Glib::Object -> A -> B inheritance tree? And maybe provide a compilable test case? Maybe you need to create an own GType for each of your derived classes. This can be accomplished by calling the Glib::ObjectBase constructor with the type name as a string. But this is only a guess. > Can't the wrapping code gkmmproc is building, try, since it really > knows (or could) the C type, work directly on that type (w/ > g_peek_class...) instead of relying on the > actual object instance type being derived directly from the C type? > d) I also saw some comments about skiping some virtual function calls. > I wonder: > 1) what's the optimization they're talking about? (haven't > checked sources enough) When a C++ wrapper is created, such as Gtk::Window, and a C virtual function is called on the underlying GObject, such as the default signal handler for the "show" signal, then we can skip calling the virtual on_show() member function of the C++ object, because it cannot be overriden anyway. However, if the same (C) virtual function is called on an instance of a derived class, such as ExampleWindow inheriting from Gtk::Window, then ExampleWindow could have overriden the on_show() (C++) virtual function, so we need to call it. > 2) (would have to check) - can they also be a source of problems > for the thing I want to have fixed? I don't think so. > Anyway, I might be mistaken, and if there is a method to accomplish > what I said in the beginning that I want, I'd be glad to hear it! > > Thanks. Armin _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
