El vie, 25-06-2004 a las 20:03, Christian Robottom Reis escribi�: > 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. > Let me say I'm not an expert of how pygtk internally works but I think the problem is GTK+ never call our methods. Please, some pygtk masters (gjc, jdahlin, ...) confirm this
> > 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? > Don't even put those two words together (TreeView + hacking). It makes me have nightmares during daylight > > 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? > I would say let's make the GTK+ guys apply my patch to have a comborender in GTK+ and then we just need to wrap it :) This way everybody is happy. If all we want is a ComboRenderer this can work, but I just put that example. We have a much more general problem in hands. > Take care, You too Lorenzo _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
