[Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable

Pierre-Yves Siret py.siret at gmail.com
Tue Mar 6 12:00:31 CET 2018


2018-03-06 11:50 GMT+01:00 Mitch Curtis <mitch.curtis at qt.io>:

> *From:* Development [mailto:development-bounces+mitch.curtis=
> qt.io at qt-project.org] *On Behalf Of *Pierre-Yves Siret
> *Sent:* Tuesday, 6 March 2018 11:29 AM
> *To:* André Somers <andre at familiesomers.nl>
> *Cc:* Qt development mailing list <development at qt-project.org>
> *Subject:* Re: [Development] Making QObject::dumpObjectTree() and
> QObject::dumpObjectInfo() invokable
>
>
>
>
>
>
>
> 2018-03-06 11:12 GMT+01:00 André Somers <andre at 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
> 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.
>
> André
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
> 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 QML:
>
>
>

That's what I meant, I generally don't want all the QObject tree, the Item
tree is enough most of the time.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180306/14367108/attachment.html>


More information about the Development mailing list