From: Development 
[] On Behalf Of 
Pierre-Yves Siret
Sent: Tuesday, 6 March 2018 11:29 AM
To: André Somers <>
Cc: Qt development mailing list <>
Subject: Re: [Development] Making QObject::dumpObjectTree() and 
QObject::dumpObjectInfo() invokable

2018-03-06 11:12 GMT+01:00 André Somers 

On 06/03/2018 11:04, Mitch Curtis wrote: makes QObject::dumpObjectTree() 
and QObject::dumpObjectInfo() invokable so that they can be used from QML. I 
think that this could be useful to debug issues, but being such a widely used 
and important class, I'm a bit unsure about whether it's worth the extra 
overhead. Here's what Olivier has to say about the overhead (taken from the 
review comments):

"The overhead here is that QObject, which is the base class of all objects, 
gets two more methods. (out of the 4 it has currently.) This means that 
QMetaObject::invoke might be slightly slower if it does not find the method. 
(But since it is currently not really optimized right now, i don't think we 
should care about this.) I don't know what that means for QML lookups, but 
probably does not matter."

So, I'm wondering what others think.

Would you use these from QML?

Would these be better off as a helper function in the Qt singleton? E.g. 
Qt.dumpObjectTree(object) and Qt.dumpObjectInfo(object).
Development mailing list<>
To be honest: no, I would probably never use them from QML. Nor do I use often 
from C++ either. I usually resort to external tooling such as GammaRay that 
give me all these methods can give me and much, much more.


Development mailing list<>

I won't either, I just tried it and it gave me too low-level information that I 
can't really exploit afterwards. I don't see a usecase where that'll help me, 
maybe you do?

I prefer my low-tech solution of recursively iterating the children or 
resources lists from QML or like André said, external tooling like GammaRay.

A helper function seems like a good compromise if it's needed.

Thanks for the feedback guys.

With regards to it giving too low-level information, I’m not sure what you 
mean. The idea is to be able to see the children of an object/item, so output 
matching that description would be on exactly the right level. :)

It seems to give more information than recursively iterating the children from 

import QtQuick 2.7
import QtQuick.Controls 2.3

ApplicationWindow {
    visible: true
    width: 640
    height: 480

    function printTree(item, indent) {
        if (indent === undefined)
            indent = 0

        if (indent === 0)

        for (var childIndex = 0; childIndex < item.children.length; 
++childIndex) {
            var pad = ""
            for (var i = 0; i < indent; ++i)
                pad += " "
            print(pad, item.children[childIndex])
            printTree(item.children[childIndex], indent)

    StackView {
        id: stackView
        initialItem: Button {
            Image {}
        Component.onCompleted: {

Output from dumpObjectTree():


Output from printTree():

qml: QQuickStackView(0x25e95f08020)
qml:  QQuickButton(0x25e95f09100)
qml:   QQuickImage(0x25e95f08890)
qml:   QQuickRectangle(0x25e95f091f0)

The idea is not necessarily to print the QObjects, but since there was already 
a function that printed everything (dumpObjectInfo()), I figure it would be 
simple enough to expose it to QML.

Shawn has a similar patch that is aimed at items:

The use case that led me to push the patch was a focus issue, if I remember 
correctly. An unnamed (no objectName) item had focus, and I couldn’t see where 
it came from.

I’m starting to lean towards a singleton helper for this, if we went ahead with 
it at all.
Development mailing list

Reply via email to