Quote Originally Posted by wysota View Post
Hmm??? Why? Expansion state is the property of the view, not the model...
Simple: my UI is generated from a XML file, describing the UI entirely. The XML file is parsed, and stored in the data structure. Therefore, I need to set the items as described in the file...


Well... that's exactly the same as you were doing before, only that instead of iterating items you are now iterating indexes. I'd suggest to keep the state in the view though...
The only "disadvantage" I see now is that the iteration must be done after the items were created, instead of when they are created (I see this as a second strep, re-iterating through the elements)...


The delegate? It is responsible for rendering a single item, not the whole tree. And it doesn't track nor change the state of data in the model.
Thanks for clarifying me this point

No, just "load" the list of expanded items from wherever you have it stored and expand those indexes that need expanding.
This might be a solution, I'll check if that can be done easily!

Why do you keep the expansion state in the model? It's against any logic relevant to model-view architecture... Visualization state of the model is not related to the data. If I expand or collapse an item in one of the views, there is no change to the data. What if I have two views of the same data and in one of them an index is collapsed and in the other it is expanded?
That's why I was saying that this "expanded" property is just used when building the tree. Think of this property as read-only in the data model: the view can use it to render the tree the first time, and the user can modify the state, but the state is not saved back into the data model.

Hope it clears a little bit why I am doing that