Hi Christian -> > On Mon, May 16, 2005 at 11:03:03AM -0600, Pete Nagy wrote: > > class A(_m.A) > > class B(_m.B, 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. > > If you /don't/ extend _m.B, and instead forward calls from B to _m.B, > you won't have (by definition) any display issues -- avoiding > inheritance just makes it work automatically. >
Well, I tried that, but it doesn't work! If _m.B subclasses gtk button, then if I create the python class B(A) and assign the ._o to a new _m.B(), it doesn't make B(A) automatically 'become' a gtk widget. Yes, I can call B_object.show() and it properly forwards the gtk call to the underlying ._o instance, but I cannot add a B_object to a gtk window the way I used to, or I get an error like: GtkTable.attach() argument 1 must be gtk.Widget, not B The way I understand it, the old pygtk would let you create a python class like B(gtk.Button), you could assign ._o to the subclass you created in your c extension module, like ._o = _m.my_btn_subclass(), and then you could use the B object itself as a gtk button. A B object that just happens to contain a pointer to a gtk button does not cut it. There is a huge amount of code that breaks in this application I am porting (OpenEV) if I cannot duplicate this previous behavior of the python wrapper class 'being' the wrapped object, instead of being a completely separate object that just happens to contain a pointer. > > The problem is that the c code creates instances in this gtk widget > > hierarchy. 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. > > Wrapping with an instance that /inherits/ from _m.B is IMO just asking > for trouble. Instead, every time you create an instance, you just create > in Python a simple (as in B(A) -- no _m.B inheritance!) wrapper class > for it. Sounds a lot easier than what you're suggesting, and IME, > avoiding inheritance /will/ pay off. > > > 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. > > Indeed. As I said, inheriting is just going to complicate things. > > /me repeats the mantra "Composition. Composition. Composition." > > Take care, > -- > Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125 > -> Pete -------------------------------------------------------------------- ==================================================================== Pete Nagy tel: (303) 583-0248 Vexcel Corporation fax: (303) 583-0246 http://www.vexcel.com home: (303) 823-2336 ==================================================================== _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
