Object Trees and Object Ownership

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. This turns out to fit the needs of GUI objects well. For example, a QAccel (keyboard accelerator) is a child of the right window, so when the user closes that window, the accelerator is deleted too.

The static function QObject::objectTrees() gives you access to all the root objects that currently exist.

QWidget, the base class of everything that shows up on the screen, extends the parent/child relationship: a child normally also becomes a so-called child widget, i.e. it is displayed in its parent's coordinate system and is graphically clipped by its parent's boundaries. Thus, when the the application deletes a message box after it's been closed, the message box' OK button is deleted too, just the way you would want, because the button is a child of the message box.

Of course, you can also delete a child object yourself, and it will remove itself from its parent. For example, when the user removes a toolbar that could often result in the application deleting one of the QToolBar objects, and the tool bar's QMainWindow parent would then notice the change and reconfigure its screen space.

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