how to get a list of QGraphicsItems with no parent?

[mooreaa]

Hello,

I am trying to save out a xml file of my qgraphicsscene and was wondering if there is a clean way to get a list of top level items aka items that do not have a prent.

I know that I can keep track of a list myself, I can parse through all objects, but aren't these things stored in the qgraphicsitem as a tree or something? I would think there would be a quick/fast way to get all top level items.

Thank you

[aamer4yu]

Wont QGraphicsScene::items () help you out ??

[mooreaa]

right... but i have to get a list of all items, and then parse throught it for top level items... this is silly when only 10 to 20% of my data is parentless.

Aren't these items stored internally as a linked list with parent and children? If so it should be able to grab the top level nodes in a single pass.

I'm playing around with a sudo schematic editor, so each component could easily have the equivilant of 20 or 100 pins each of which are seperate graphcisitems. So when I grab all items, I'm going through TONS of objects.

Just doesn't seem very efficient.

[aamer4yu]

Am not sure if items return only the top level items in the scene or their children too. Have u tried it ?

Else U have to iterate over all the items and check their parent. The code wont be that long...

Other way around is,,, keep a separate list of items in ur class. While adding items to the scene, add it to the list too, if it does not have a parent item. In that way u will have the list ready when u want to save the items

[mooreaa]

the QGraphicsScene's items() function returns all objects in a scene.

From a coding standpoint, it is poor design to duplicate a data structure that already exists. Its is an easy source for bugs.

Yes the code to parse throught parents is indeed very short as stated previously, but the speed is also linear with the number of items in the scene, which, in my case is far from optimal.

What I am saying is that the data structure exists in QGraphicsView. They provide accesors based on space, why not have a hierarchical way of walking/accessing the same tree/data.

[aamer4yu]

Theres always a compromise on space or time.
If u iterate the items, u are gaining space but losing time.

If u keep pointers, u gain time but lose space. Also we are not actually doing a deep duplicate of the list. Just keep pointers.

Cant think of some other solution, and not aware if Qt provides a way to traverse a tree using BFS.

[mooreaa]

I'm not talking about coding space as much as I'm saying that trying to duplicate an existing data structure is bad coding.

What is the mechenism that will store your list? Who keeps track of it? How will it know when to update? As an example, if you inherit from qgraphicsitem and put code in the constructor to append to a master list, then all your objects that are derived from this subbed class will be auto add to the list (a la autolist pattern). This works well, except now look at how an undo/redo framework might be adding removing objects from the scene. In my case the object isn't destoryed and recreated, the pointer to the object is held by the undo framework while the object is removed from the scene list. This will not cause your list to be properly updated so you will need to modify this list now from your undo/redo statements.

What if you wan't to add a generic object? You won't have the convenience of the autolist pattern, so you'd have to do the tracking somewhere higher up. Now you can see how the code to track objects starts sprawling throught the code.

Imagine creating and destorying hundreds of objects at a time in a scene and keeping a list of them. If you had a bug anywhere this list would become out of sync, but might go unoticed in a subtle way becoming a typical "software bug".

This is why I feel that using the built in accesor methods is the better choice for now. The problem then becomes in the optimization of that. Clearly you can see how its not efficient to get a list of all objects just to only use a few of them.

I'm saying that as Graphics View matures, one of the important features it might look at is the power of other Scene Graphing software. They let you do optimized selections to improve the speed/reliability rather then forcing others to reduplicate structures elsewhere. This seems fundamental in order to improve the capabilities of Qt and to improve upon thier great framework.