Bug 619 – never automatically delete a QWidget that has no parent widget and is visible

PySide Bugzilla Closed for New Bugs

PySide is now a Qt Add-on and uses the Qt Project's JIRA Bug Tracker instead of this Bugzilla instance. This Bugzilla is left for reference purposes.

Bug 619 - never automatically delete a QWidget that has no parent widget and is visible

Summary:

never automatically delete a QWidget that has no parent widget and is visible

Status:	CLOSED INVALID

Product:	PySide
Classification:	Unclassified
Component:	PySide
Version:	HEAD
Platform:	All All

Importance:	P3 normal
Assigned To:	renato filho

URL:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2011-01-17 15:37 EET by Farsmo
Modified:	2011-01-21 15:44 EET (History)
CC List:	8 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Farsmo 2011-01-17 15:37:49 EET

Currently,

    QLabel("Hello world").show()

fails (by only displaying the QLabel for a split second) while

    w = QLabel("Hello world")
    w.show()

works correctly. This behavior is undesirable for a garbage-collected
high-level language like Python, as the semantics shouldn't change so
drastically depending on the exact lifetime of the object.

This is also a big limitation to any solution to bug 606 because it would not
be possible to isolate the widget-generating code in a main() function that
does not manipulate the QApplication, as the widgets would be garbage-collected
before app.exec_() can ever be called.


The implementation could be relatively straightforward: before deleting a
QWidget w owned by PySide, if we detect that QApplication.instance() is not
None, that w.isVisible() and that w.parentWidget() is None, instead of deleting
w we can place it in an internal list that we will only destroy once the
QApplication is deleted.

We could consider exposing that list to the user, but since the content of such
a list depends on the specifics of garbage-collection, I think it's a bad idea:
programs that depend on it could suddenly stop working correctly in a
non-reference-counted implementation of Python.

There might be backward-compatibility implications in two cases:
- an application relies on garbage-collection to hide and destroy windows, for
example by setting self.myWindow = None to hide a top-level window (this would
only work if it is not in the QObject tree of self)
- an application creates useless top-level windows that get destroyed almost
immediately in the current implementation

This can be a concern, but both cases can be considered bugs as they would fail
with other garbage-collection schemes, and if they actually happened they would
be easy to detect and remedy as they would show up as lingering top-level
windows.

Comment 1 renato filho 2011-01-17 15:53:56 EET

In my option this behavior break all Qt architecture. The parent policy exists
to avoid mistakes and optimizations.

If you implement this behavior you can cause a mess on Qt parent control, and a
lot of widget will be alive in memory during all the application life. this
will be a lot of wasted memory.


The Qt policy is the best way to control the objects life, let's keep this way.

Comment 2 renato filho 2011-01-17 15:55:48 EET

but please, if you disagree with me you can propose a PSEP to a new parent
control policy to be implemented on PySide.

Comment 3 Matti Airas 2011-01-17 15:57:41 EET

I'm resolving this invalid.

Comment 4 Farsmo 2011-01-17 16:43:56 EET

> In my option this behavior break all Qt architecture. The parent policy exists
> to avoid mistakes and optimizations.

A laudable goal, but the truth is that in Python the parent system cannot
really be relied upon: a custom widget can store, say, a QTimer to self.timer
and neglect to make it its child. It is guaranteed to work because the Python
object holds the reference to self.timer, and although not Qt-iful it's
perfectly correct. So the truth is that a Qt app developed entirely in Python
is likely to contain many such instances of objects that do not obey the parent
policy.

I'm not saying it's a good thing: the QTimer might get destroyed later than
necessary if the garbage collection is a bit lazy.


> If you implement this behavior you can cause a mess on Qt parent control, and a
> lot of widget will be alive in memory during all the application life. this
> will be a lot of wasted memory.

For the QTimer example I gave, that would be a valid concern, but this has
nothing to do with what I'm proposing: in all its lifetime, the application
will not create any more parentWidget-less visible widgets than it will create
windows, and those widgets will be destroyed when the window is closed, so
there is absolutely no potential for memory leaks.

Or, equivalently: it shouldn't change a thing for current applications, in
behavior as well as in memory usage, except in the two cases I talked about in
the bug report.

Comment 5 renato filho 2011-01-21 15:44:51 EET

release beta4