On Sex, 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.
The GenericGtkFooBar are the old way of doing this and are deprecated. Nowadays you can subclass any gtk.XxxCellRenderer and override specific vfuncs. Take a look at (define-virtual ...) blocks in the .defs. Regards, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
