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 specificvfuncs. Take a look at (define-virtual ...) blocks in the .defs. Regards, -- 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
