Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Find *ALL* QGraphicsItems?



  • For developing/debugging, I found QWidgetList QApplication::allWidgets() very useful, especially to track down "orphaned" widgets.

    Now moving to QGraphicsScene I don't see/suppose there is any equivalent to walk all QGraphicsItems created in the application, an equivalent QApplication::allGraphicsItems()? The whole point is to find any which do not have a parent QGrapchicsScene, so QGraphicsScene::items() is not going to help me....


  • Qt Champions 2019

    Ok, then 'no' :)


  • Lifetime Qt Champion

    Hi,

    What kind of parentless items do you have in mind ?



  • @SGaist

    1. Any QGraphicsItem created via new QGraphicsItem::QGraphicsItem(nullptr) and then not later added via QGraphicsScene::addItem().

    2. Any QGraphicsItem created via new QGraphicsItem::QGraphicsItem(parentQGraphicsItem) which, when then you walk up the parentQGraphicsItem tree, ends up at an ancestor created via new QGraphicsItem::QGraphicsItem(nullptr).

    3. Any QGraphicsItem removed via QGraphicsScene::removeItem() where the caller has failed to then delete/deleteLater() the item and/or its descendants.

    4. Any QGraphicsItem which I think I have removed/deleted, but Python is still holding a reference to, for whatever reason.

    5. The ability in debugging code to be able to search all QGraphicsScenes the app might have with items where, for whatever reason, I do not have/it is not convenient to have a list of the top-level QGraphicsScenes to pass to it as parameters in order to do the descent walking, and so would like a "global" list to get going from.

    That's a start! Remember, this is for developing/debugging.

    I used this principle via QApplication.allWidgets() in last project debugging, and believe me it did show up "orphans" which I had to deal with!

    As you know, in other people's posts we quite often point out that have done some new QWidget() but failed to parent it or delete it, and are therefore leaking. If they tried walking QApplication.allWidgets() they would spot these, including the "nasty" where they have a whole bunch of widgets with parents but the top-level parent is orphaned (which my walk code detects), and are therefore leaking a lot....


  • Qt Champions 2019

    This is a task for a memory leak check like e.g. valgrind. Since you're responsible for the objects you create, you have to take care to delete them (or use a proper parent-child relationship). I don't see how Qt can do something for you here since it's basic c++.



  • @Christian-Ehrlicher
    You know I respect your input, but sorry I don't think you're being reasonable. I'm not programming in C++. valgrind does not work at all well with Python. You cannot use it examine relationships, print out hierarchies etc. of what is there as you can from within your own code. "proper parent-child relationship" is not at all the whole story from Python as it is from C++.

    What you say applies just as much as QApplication.allWidgets(), yet that seems to (happen to) be provided, where (from my investigations so far) QApplication.allGraphicsItems() does not. I merely asked if anyone knew of something like that I could use. Qt could choose to do that. If the answer is no there is not, that's it. I'm not criticising Qt, I'm just asking....


  • Qt Champions 2019

    @JonB said in Find *ALL* QGraphicsItems?:

    Qt could choose to do that.

    Sorry but Qt is not responsible for your memory management. If you want something like a management for this you have to do it on your own.



  • @Christian-Ehrlicher
    Forget everything about memory management. I asked whether anyone knows if Qt provides an application-level QApplication.allGraphicsItems()-type method, or equivalent, like it does for QApplication.allWidgets()? Very simple question.

    If you or @SGaist feel fairly sure the answer is no, as I presume it is though nobody will just say so, shall I just close this issue?


  • Qt Champions 2019

    Ok, then 'no' :)



  • @Christian-Ehrlicher

    Ok, then 'no' :)

    Soooo much better, clearer & quicker! :) I appreciate your time & input. As you can see, I have marked that as the Solution Answer. Thank you!


Log in to reply