On Fri, Jun 25, 2004 at 06:43:09PM +0200, Lorenzo Gil Sanchez wrote: > > There are various bug reports scattered around relating to this, but I think > > this is the mother of them all: > > > > http://bugzilla.gnome.org/show_bug.cgi?id=129843 > > You are right that bug is related with the problem we are discussing > here but please note that even if that bug is solved we still can't > override GTK+ C methods in Python which is what I understand stop us > from having *full* support to subclass Widgets.
So I understand, is the problem that we can't override it (the class parsing or instantiation fails) or that GTK+ never calls out methods? If the latter, I guess I understand why, and we'd need to look at another strategy for clobbering them. > For example, here we have a GTK+ C Object: GtkCellRendererText and if I > subclass it from Python like > > class CellRendererCombo(gtk.CellRendererText): > pass > > there is no way I can override the start_editing method of > GtkCellRendererText, which is all we need to have a combo box inside a > TreeView. We could of course try and add a hack that allowed this -- perhaps something that did evil TreeView hacking. What do you think? > A possible work around would be to define each and every method that is > a good candidate to be overriden to be a signal (since we can override > signals in pygtk) but this means changing a lot of code in GTK+ which I > see undoable for practical reasons. It depends on what you want. If this is blocking us from implementing a Combo renderer, then I think we could very well push to get at least this specific one changed. What do you say? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
