Custom Branch in QTreeView/QFileSystemModel
I’m currently using a combination of QFileSystemModel, QSortFilterProxyModel, and QTreeView to display the sorted contents of a directory, limited to specific file types. What I would like to do, now, is add a custom branch to the bottom of the tree. In the attached image, the desired effect is shown (as seen in another, non-Qt program).
The “Lib” branch does not refer to any directory. It is actually a list of libraries based on the result of parsing a config file. What I would like to do is extend my setup to include an additional branch similar to this. I have looked at the reference documentation for all of QFileSystemModel, QSortFilterProxyModel, and QAbstractProxyModel; however, I am unsure how to go about adding an additional row/branch while still maintaining the full functionality of the QFileSystemModel. Any assistance would be appreciated.
I had considered that method already, as I am currently using a QSortFilterProxyModel for sorting and filtering. But how do I create the QModelIndex objects for the proxy model, and how then do I differentiate between the fake objects and the ones provided by QFileSystemModel? Further, if the row exists only in the proxy model, what would mapToSource() return?
But how do I create the QModelIndex objects for the proxy model, and how then do I differentiate between the fake objects and the ones provided by QFileSystemModel?
By hand: you need to know what is being added by your proxy and what is being mapped from the proxyed model. Store that information somewhere.
Further, if the row exists only in the proxy model, what would mapToSource() return?
An invalid model index? I’d just override every single virtual you have there and provide the behaviour you want.
Actually, you may also avoid QAbstractProxyModel entirely and create your own QAbstractItemModel subclass, fetching data from the QFileSystemModel…
What might work for you too, is to use two models, and use a proxy to merge them. I think that in the KDE source code, there is already a proxy model that can merge two item models. If you use a QStandardItemModel for your libs tree, then you should be able to use QFileSystemModel for your file system view. It is not a trivial class to re-create yourself, especially because it uses threading and watches the file system for changes in the visible parts of the model.