Fw: [PyKDE] Destructor trouble (how to get rid of child widgets ?)

[Phil Thompson]

Thomas Malik wrote:
> 
> > So, what to do about it? I can't think of a way to make this transparent
> > to the programmer. All I can think of at the moment is to implement
> > /TransferBack/ (ie. transfer ownership back to Python) and add it to
> > QObject.removeChild(). The following code should then work...
> >
> > self.removeChild(self.box)
> > del self.box
> >
> he he, so just why was i thinking about the very same possibility ...? That
> would help a lot.
> I did a 'workaround' by adding a 'widgetStack' accessor function to the
> QTabDialog class. Having this, i can at least do a 'removeWidget' call on
> the QWidgetStack, getting rid of the 'Properties' page. However, it still
> lurks in memory, and that solution does not work for the case where i use a
> simple QDialog, where the Properties page sits in.
> Maybe adding extra functionality to removeChild is the right thing, it could
> decrease the refcnt and completely delete the child if the refcnt drops to 0
> (so you won't get a memory leak).

In http://www.river-bank.demon.co.uk/software/private you'll find
v0.13pre1 which implements the TransferBack. However, it doesn't make
any different to your sample script because you still seem to have an
extra reference to the QGridLayout lying around somewhere.

> So, how exactly do the QObject & PyObjects in your library relate ? Are your
> Python objects just wrappers around the C++ object pointers, or how else is
> it set up ? I understand that by 'ownership Transfer' you mean memory
> management responsibility, but i don't see how you tell Python about when Qt
> deletes an object.

If you create a Python instance of a wrapped class and look in its
dictionary, ie...

o = QObject()
dir(o)

...you'll see an object called "sipThis". This is, effectively, a C data
structure that contains (amongst other things) the address of the
underlying C++ object.

The bindings do the best they can to detect when a C++ object
disappears, but it can't be foolproof. There may be times, even if the
ownership rules are correct, when a Python object still exists and
points to a non-existent C++ object - and if you try to use it you'll
get a segv. However, in practice, a more likely cause of segvs is
getting the ownership rules wrong (ie. missing Transfers).

Phil