On Ter, 2006-11-28 at 10:01 +0100, Hrvoje Nikšić wrote:> On Tue, 2006-11-28 at 04:57 +0100, John K Luebs wrote:> > > The idea is to reuse GObject facilities where possible (e.g. types, > > > inheritance, signals, GValues), and simply implement the> > appropriate > > > vtable semantics overridable at runtime. I was wondering if anyone> > else > > > has stumbled on this and already solved it.> > > > This is precisely what pygtk tries to do. > [...]> > I can't see what is wrong with the way pygtk does things> > The PyGTK approach requires writing a piece of glue C code for every> class whose methods need to be overridden. See the example of> GtkCellRenderer.
Yes and no:
1- Forget about GenericCellRenderer; it is old code, we have a newbetter way of doing things;
2- Whether or not (define-virtual ...) causes generation of all"virtual proxies" and "virtual accessors" (as I call them) depends onthe parameters. Some parameters have out or inout semantics and so aredifficult to generate. But it's the same problem as for the rest ofthe .defs: most methods are automatically generated, some need manualcode to go into a .override file.
The way of the future is the gobject-introspection module, butunfortunately it is taking too long to be picked up by glibdevelopers :-(
-- Gustavo J. A. M. Carneiro<gjc@xxxxxxxxxxxxx> <gustavo@xxxxxxxxxxxxxxxxxxxxx>The universe is always one step beyond logic.
_______________________________________________gtk-list mailing listgtk-list@xxxxxxxxxxxxx://mail.gnome.org/mailman/listinfo/gtk-list
