2018-03-06 11:12 GMT+01:00 André Somers <an...@familiesomers.nl>:
> On 06/03/2018 11:04, Mitch Curtis wrote:
>> https://codereview.qt-project.org/#/c/221758/ 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.
Development mailing list