On Mon, 29 Sep 2003 15:08:54, Gordon Tyler wrote: > David Boddie wrote:
> > KHTMLPart *part = (KHTMLPart *) parent(); > > I don't think that sort of concept really makes sense in Python. > Type-casting in C/C++ just determines the particular interface through > which your code is then accessing the object, it doesn't change the > object's intrinsic type. Python only ever deals with an object's > intrinsic type since it's a dynamically typed language. Sure. The problem I think I have is that I'm always likely to be presented with something that's wrapped as a QObject. I create a factory class based on KLibFactory which is instantiated by a calling application. This creates instances of a KPart.Plugin-based class on demand from the application; its parent is a QObject. Now, when my Plugin instance receives a signal, it checks its parent widget/object using self.parent() only to discover that its a different QObject. I suspect that this is because it gets embedded into a widget by the application. The point is that the parent is actually a KHTMLPart, but it could be anything as far as I can tell. > However, the problem may be that the sip translation is not translating > that subclass. See my earlier patch for some subclass mapping that Jim > extended and incorporated into one of the 3.8rc releases. I'm using 3.8rc2, but I think that the above issue may lie outside the scope of your patches. The subclass mapping works well in PyKDE; the above problem is either the result of misinterpretation on my part, or something in a grey area between C++ and Python. It's a case of working around the use of pointers in the underlying framework which are only there to provide a flavour of dynamic typing in a statically typed system. As I understand it, anyway... David _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
