On Fri, 2006-11-24 at 11:29 +0100, Hrvoje Nikšić wrote:> On Fri, 2006-11-24 at 10:33 +0100, Murray Cumming wrote:> > On Thu, 2006-11-23 at 12:27 +0100, Hrvoje Nikšić wrote: > > [snip] > > > The problem is that the fields of XyzClass and its descendants are> > C > > > struct members, as inaccessible to Python code as any field of a C > > > struct, at least without heavy ctypes hackery. > > [snip]> > > > But I guess that pygtk (like other bindings) has a standard way of > > wrapping these, because they are needed in order to implement custom > > GtkTreeModels or GtkCellRenderers, among other things.> > As far as I can tell by looking at gtk/pygtkcellrenderer.c, PyGTK allows> overriding by creating a "stub class" PyGtkGenericCellRenderer that> inherits GtkCellRenderer and overrides its C methods with its own> methods that call into Python. GtkTreeModel is handled exactly the> same.> > While this approach works for a specific class, it requires writing> non-trivial glue code for each class that needs to be subclassed. It> doesn't allow a Python programmer to subclass a given GObject class> directly from Python. If that glue code is hand-coded, I guess it's repetitive and can begenerated somehow. In a future pygtk that uses the future introspectionfeatures of GObject, it could probably even be done at runtime forarbitrary GObjects. Gtkmm generates the equivalent glue code for this given1. the desired signature of the C++ virtual function via e.g._WRAP_VFUNC(void do_something(int thing), do_something)2. the signature of the C vfunc, in our hand-writtenlibsomethingorother_vfuncs.defs file.3. Conversions between the C parameters and the C++ parameters. -- Murray Cummingmurrayc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx _______________________________________________gtk-list mailing listgtk-list@xxxxxxxxxxxxx://mail.gnome.org/mailman/listinfo/gtk-list
