QFileSystemModel - iterating through current index children
-
The problem may be, that AFAIK, QFileSystemModel does its fetching of nodes in a background thread. That could mean that while fetchMore(index) triggers such a background scan, the model is not actually modified until that background thread is done doing its magic. The call to fetchMore(index) would simply return immediately, and rowCount(index) on line 15 would not be updated yet.
Note that the above is just conjecture. I did not try this myself, nor did I take a peek at the source code.
-
[quote author="Andre" date="1302679754"]The problem may be, that AFAIK, QFileSystemModel does its fetching of nodes in a background thread. That could mean that while fetchMore(index) triggers such a background scan, the model is not actually modified until that background thread is done doing its magic. The call to fetchMore(index) would simply return immediately, and rowCount(index) on line 15 would not be updated yet.
Note that the above is just conjecture. I did not try this myself, nor did I take a peek at the source code. [/quote]
I think it works exactly this way.
If you have a QFileSystemModel connected to a QTreeView and open folders on slow drives, the content comes in part by part. -
this seems to be what is happening because over time, there are more and more nodes being displayed. Is there an indication to when the fetch is complete? Better yet, what would be a better methodology for accomplishing my task? As you can see, I am trying to recursively check/uncheck all children nodes when the parent node is checked/unchecked. Also, there will be logic to uncheck any parent node if any of its child is unchecked. Thanks!
-
I would start to re-think your logic, I think. Think if you can come up with a method that does not require that every node is loaded.
You could, for instance, do something like this:
Each leaf node can have three states:Checked
Unchecked
Determined by parent
A fourth state is added for each branch-node: Determined by children
The default, implicit state for each node with the exception of the root node would be that it is determined by its parent. Note that if a branch-node's state is determined by its children, it can get the "partially checked" ambivalent value.
If your user checks or unchecks a branch node that was determined by its parent before, you only need to do three things:
Set the state for this branch to the appropriate explicit new state checked or unchecked
Set the state of the siblings of this branch to reflect the (common) parents' state
Set the parents to the "determined by children" state
If your user checks or unchecks a branch node that was determined by its children before, you need to:
Set the new state on the branch node
Set iteratively set each (existing!) child node state to "Determined by parent" (or, dump that part of your data, keeping in mind that we agreed that "Determined by parent" is the default state anyway.
For determining the actual visualized state of a check box, you end up with something like this:
- If the state is "determined by parent", the state is the same as for the parent node
- If the state is one of the explicit states, then the state is clear
- If the state is "determined by children", then iterate over the (existing!) child nodes. If they are all the same, then the state is that state, otherwise the state is the ambivalent PartlyChecked state.
Of course, the above picture is not complete. It is just to illustrate a way you can add check boxes to a tree without having to have access to the full tree. Observe that in the case of your QFileSystemModel tree model, you will probably only need to keep track of the states of just a few nodes. The rest of them will be determined implicitly. Still, to the user, checking a single directory will appear to check perhaps thousands of files under it, without the code actually having to iterate into the complete directory structure under it.
-
bq. If the state is “determined by children”, then iterate over the (existing!) child nodes. If they are all the same, then the state is that state, otherwise the state is the ambivalent PartlyChecked state.
Thanks for your response. However, a concern I have is that I will still have to fetchMore (an indefinite procedure) to iterate over the (existing) child nodes.
-
No, you don't. That's the whole beauty of the idea. :-)
You only need to iterate over the children that you already have. Potential children that have not been loaded yet, will have the default Determined by parent state.
Edit:
Perhaps there could be a slight snag though, if you are in a large directory, perhaps it could occur that not all files in that directory are loaded yet when you start modifying check boxes in it. That might be a point of breakdown. That could be solved by introducing something like a "default state for child nodes" for all branch nodes. Set that, and have nodes that have just been added take over that state. -
Just so that we are on the same page because the topic doesn´t describe my issue in details. I am using a QTreeView populated with a subclassed QFileSystemModel. I´ve been successful at integrating a checkbox in column 0 of each tree node (a row) and have also added another column to my treeview. I am running into the issue of propagating the state of the parent node to the children when it´s state change as well as propagating the state of the parent node to uncheck if any of its child is unchecked or to check if all of its child is checked. Eventually, my goal will be to iterate through all of the check nodes (files) in the treeview and process them.
-
The snippets you requested have turned into a complete class. The principle works, -but there is still an issue to iron out that sometimes, an infinate recursion is triggered and the application crashes. That, of course, is not acceptable.-
Still, working with a QFileSystemModel as the base model, the proxy nicely manages to add checkboxes to each node, and make branch nodes work as expected (checking or unchecking them will do the same for the whole subtree, while having both checked and unchecked nodes in the subtree results in the Partially Checked checkbox state). That works with a minimum number of items that are actually tracked. In a realistic scenario on a pretty big file system, I still only had a few dozen items in the internal data store that tracks the check state of each node. The proxy model automatically reduces the number of size of the internal data store to a minimum. Obviously, all that works without recursing into the base model more deeply than the user already has, let alone trying to iterate over all children and trying to make the model fetch all of them. :-)
Now that I have a complete class, the question arises under what licence to publish it. Do you need it for an open source project, or do you need something compatible with a closed source application? It turned out to be quite a bit of work to get working, even though the principles are actually the same as I described on the previous page of this topic. That makes me a bit reluctant to just dump it into the public domain...
Edit:
I have managed to resolve the issue, I think. At least the class now seems to work reliably under my tests. See screenshot below for how it looks:
!http://dl.dropbox.com/u/16442531/CheckableProxyModelDemo.png(Screenshot of CheckableProxyModel class applied to a QFileSystemModel)!What kind of additional API would be needed, you think? I am thinking along these lines:
An API to set the default state of all the nodes to either checked or unchecked (done)
An API to list the checked subtrees (QModelIndexList with the top nodes that have everything under them checked) (done)
An API to list the checked branch nodes (also a QModelIndexList) (done)
Signals to indicate when 1 or 2 changes (done, though only one change signal for now)
... ?
Will we need convenience API to set the check-state programatically? I mean, you can already do that of course by using QAbstractItemModel::setData() just like the view does, but perhaps that could be made easier. What might be handy is to be able to specify the check state based on the source models QModelIndex-es. That way, it would be easy to set for instance the check state based on the file path when using a QFileSystemModel as the source model.
-
I am thinking of the best way to do this, yes. I'm not sure if it should be a Qt contribution, or some other third party component, nor I am sure if I could perhaps make some kind of dual licence for it.
Edit: a suggestion at #qt-labs was to make it into a Qt example. That might work.