QT: QFileSystemModel _q_fileSystemChanged slot is executed in the user interface thread, which contradicts the documentation

Question

My user interface uses QTreeView with QFileSystemModel to select folders and files. The documentation for QFileSystemModel says that updating the file structure is done on a separate thread, which means that the user interface will not be blocked. However, this does not apply to me, and I cannot understand how discriminated and how other people do not face this problem. After debugging, I noticed that the QFileSystemModel _q_fileSystemChanged slot, which takes up most of the time, is still executed in the main user interface thread, which makes sense. The question is, as stated in the documentation, that it will not block the user interface. Is there a solution? I do not understand something?

To play - Create a QTreeView with QFileSystemDataModel - Set the root path to "or" / "- Set a breakpoint in the QFileSystemModel _q_fileSystemChanged slot - Expand one of the drives after loading the application.

Problem: - The slot is called in the user interface thread, blocking the application until it is completed.

There are ways to make the file parser faster, but I really need to execute a separate thread and let me know when the data is full and ready for QTreeView.

Thank Innocent

Answer 1

I think the reason for this may be icons. Within _q_fileSystemChanged() slot receives a call that, among other things, resolves icons for paths. In it, the current QFileIconProvider design uses QIcon to represent icons, and QIcon can only be used in the user interface thread. QImage seems to be the only class allowed for use in other threads, but I think it’s expensive to use QImage in the background thread and convert it to QIcon in the user interface thread.

Thus, it is possible that the implementation of the QFileIconProvider platform in some cases is slow on network paths and therefore slows down the main user interface thread.

I do not know if this is the source of your problem, but at least this should be the reason that _q_fileSystemChanged() is called in the user interface thread.