Hi Christian -> > On Fri, May 13, 2005 at 01:23:14PM -0600, Pete Nagy wrote: > > I am having trouble porting an application from gtk1.2 to gtk2. I have > > a c module with subclasses with corresponding python wrapper classes. > > I know exactly what you mean. This is one of the consequences of the > "wrapping model" having changed with PyGTK-2. > > > The python classes could add extra code to the wrapped c module classes, > > and you could create a new C object by simply assigning an instance of > > _m.c to the ._o in the C instance, and then with the C instance you could > > call all _m.c functions as well as the additional methods added at the > > pure python level in classes C, B or A. > > Yes, but this also resulted in some unexpected behaviour: the widget > wrapper received in a callback would be of the "original" type, and > there was overhead for just instantiating all these Python wrappers. The > new model is a bit less flexible but "more correct". > > I'm totally the "quotes guy" today! > > > What I really want is to replicate what was possible with the old > > pygtk, which is create a new instance of B at the python level that > > wraps the _m.b instance, so that calls to functions in B are really > > calls to the underlying _m.b instance. > > Why not implement the wrapper and proxy yourself, using something like a > special __getattr__ hook that passes calls to the underlying GtkObject? > It's not a complete solution, but it may work in your case. > > > I have tried having the B(_m.b, A) __init__ method take an _m.b > > parameter, and if specified then I bypass the _m.b init call (which would > > create a second instance of _m.b, which would be bad), and instead assign > > the _m.b instance to a ._o attribute, and I modifiy __getattribute__ to > > pass any calls to the ._o, if it exists. This works in that I can call > > _m.b methods using the B object, but not all of the magic is working, > > as B is not considered an initialized instance of _m.b, and these gtk > > widgets don't display properly. > > Hmmm. Too many underscores for me to grok in these 30 seconds. Why do > you need to inherit from _m.b? Simple composition should work for the > simpler cases, shouldn't it?
Thanks for the reply. Sorry about too many underscores; I am trying to simplify without oversimplifying! Anyway, with the example: class A(_m.A) class B(_m.B, A) This works wonderfully if I only create new objects on the pure python side. By extending _m.B and A I have access to all of the _m.B and _m.A functions written in c, as well as the additional python methods defined in B and A. I think you were suggesting that I do not need to extend _m.B, if I have a ._o and __getattr__ forwarding. That's true, but I thought extending _m.B might be cleaner, and right now is the only way these gtk widgets display properly. The problem is that the c code creates instances in this gtk widget hierarchy. class C might have have a function get_B() which in the python code would return a _m.B. But on the pure python side I don't want to deal with an _m.B object. I want to wrap the _m.B instance with a new instance of class B(_m.B, A), so that I can get all of the additional functionality defined at the pure python level for A and B. When I assign the existing instance of the _m.B to ._o in the new python B object, the proxy stuff works - __getattribute__ lets me call _m.B, _m.A functions and python methods. But, there is apparently something else required other than just forwarding getattr, because these gtk widgets do not display. If I print str(object) then I get something like: <B object (uninitialized) at 0xc58e68> After all, I do not call the _m.B.__init__() method when I already have an _m.B object to wrap, as this would create another instance. Any more advice on how this new built-in type stuff works, and how we can fool the class into thinking it's initialized when we have an instance of its superclass to wrap? Does this problem sound familiar to someone with experience with the old pygtk design, or with proxy issues? I've tried looking at swig too, but so far no solution/inspiration. I was kind of hoping this problem has bitten somebody else before now... Cheers, -> Pete > > Take care, > -- > Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125 > _______________________________________________ > pygtk mailing list [email protected] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ > _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
