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 allQGraphicsItems
created in the application, an equivalentQApplication::allGraphicsItems()
? The whole point is to find any which do not have a parentQGrapchicsScene
, soQGraphicsScene::items()
is not going to help me.... -
Ok, then 'no' :)
-
Hi,
What kind of parentless items do you have in mind ?
-
-
Any
QGraphicsItem
created vianew QGraphicsItem::QGraphicsItem(nullptr)
and then not later added viaQGraphicsScene::addItem()
. -
Any
QGraphicsItem
created vianew QGraphicsItem::QGraphicsItem(parentQGraphicsItem)
which, when then you walk up theparentQGraphicsItem
tree, ends up at an ancestor created vianew QGraphicsItem::QGraphicsItem(nullptr)
. -
Any
QGraphicsItem
removed viaQGraphicsScene::removeItem()
where the caller has failed to thendelete
/deleteLater()
the item and/or its descendants. -
Any
QGraphicsItem
which I think I have removed/deleted, but Python is still holding a reference to, for whatever reason. -
The ability in debugging code to be able to search all
QGraphicsScene
s 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-levelQGraphicsScene
s 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 walkingQApplication.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.... -
-
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++.
-
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.... -
@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.
-
@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-levelQApplication.allGraphicsItems()
-type method, or equivalent, like it does forQApplication.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?
-
Ok, then 'no' :)
-
Ok, then 'no' :)
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!