Warning

This section contains snippets that were automatically translated from C++ to Python and may contain errors.

Object Trees & Ownership

Information about the parent-child pattern used to describe object ownership in Qt.

Overview

QObjects organize themselves in object trees. When you create a QObject with another object as parent, it’s added to the parent’s children() list, and is deleted when the parent is. It turns out that this approach fits the needs of GUI objects very well. For example, a QShortcut (keyboard shortcut) is a child of the relevant window, so when the user closes that window, the shortcut is deleted too.

QQuickItem, the basic visual element of the Qt Quick module, inherits from QObject , but has a concept of the visual parent which differs from that of the ** QObject parent. An item’s visual parent may not necessarily be the same as its object parent. See Concepts - Visual Parent in Qt Quick for more details.

QWidget, the fundamental class of the Qt Widgets module, extends the parent-child relationship. A child normally also becomes a child widget, i.e. it is displayed in its parent’s coordinate system and is graphically clipped by its parent’s boundaries. For example, when the application deletes a message box after it has been closed, the message box’s buttons and label are also deleted, just as we’d want, because the buttons and label are children of the message box.

You can also delete child objects yourself, and they will remove themselves from their parents. For example, when the user removes a toolbar it may lead to the application deleting one of its QToolBar objects, in which case the tool bar’s QMainWindow parent would detect the change and reconfigure its screen space accordingly.

The debugging functions dumpObjectTree() and dumpObjectInfo() are often useful when an application looks or acts strangely.

Construction/Destruction Order of QObjects

When QObjects are created on the heap (i.e., created with new), a tree can be constructed from them in any order, and later, the objects in the tree can be destroyed in any order. When any QObject in the tree is deleted, if the object has a parent, the destructor automatically removes the object from its parent. If the object has children, the destructor automatically deletes each child. No QObject is deleted twice, regardless of the order of destruction.

When QObjects are created on the stack, the same behavior applies. Normally, the order of destruction still doesn’t present a problem. Consider the following snippet:

if __name__ == "__main__":

    window = QWidget()
    quit = QPushButton("Quit", window)
    ...

The parent, window, and the child, quit, are both QObjects because QPushButton inherits QWidget, and QWidget inherits QObject . This code is correct: the destructor of quit is not called twice because the C++ language standard (ISO/IEC 14882:2003) specifies that destructors of local objects are called in the reverse order of their constructors. Therefore, the destructor of the child, quit, is called first, and it removes itself from its parent, window, before the destructor of window is called.

But now consider what happens if we swap the order of construction, as shown in this second snippet:

if __name__ == "__main__":

    quit = QPushButton("Quit")
    window = QWidget()
    quit.setParent(window)
    ...

In this case, the order of destruction causes a problem. The parent’s destructor is called first because it was created last. It then calls the destructor of its child, quit, which is incorrect because quit is a local variable. When quit subsequently goes out of scope, its destructor is called again, this time correctly, but the damage has already been done.