On Tue, Nov 28, 2006 at 10:01:45AM +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. People have told you to look at define-virtual to see how it works. Youobviously didn't look at the example I told you to look at. Don't you get it: If you have static traditional C structs with noruntime based value marshalling and introspection, you HAVE TO HAVE GLUECODE. There is no way around it. The glue might be the wrapper itself,or it may be magic that ties into libffi, but you have to have the glue. You made it a requirement that the native C performance not suffer, orat least it sounded that way from an earlier post. I am not questioningthe validity of this requirement (even though it would be a good idea),but you will have to generate wrapping code for every struct or classyou want to wrap. As has been shown to you multiple times, this code canbe generated automatically, and with careful use of C types and somestandardization you can get 100% coverage from the generated code withno need to manually wrap anything. -jkl_______________________________________________gtk-list mailing listgtk-list@xxxxxxxxxxxxx://mail.gnome.org/mailman/listinfo/gtk-list
