QT:QFileSystemModel _q_fileSystemChanged插槽在与文档相反的UI线程上执行 [英] QT: QFileSystemModel _q_fileSystemChanged slot is executed on the UI thread which contradicts documentation

问题描述

我的UI使用QTreeView和QFileSystemModel来选择文件夹和文件. QFileSystemModel的文档说，文件结构更新是在单独的线程上完成的，这意味着不会阻止UI.但是，对我而言并非如此，我无法弄清楚差异以及其他人是如何遇到此问题的.调试后，我注意到占用大部分时间的QFileSystemModel _q_fileSystemChanged插槽仍在有意义的主UI线程上执行. Questiong是文档如何声称不会阻止UI的.有解决方案吗?我误会了吗?

My UI is using QTreeView with QFileSystemModel to be able to select folders and files. The documentation for QFileSystemModel says that file structure update is done on a seperate thread which would mean the UI would not be blocked. However, this is not the case for me and I can't figure out the discreptency and how other people are not running into this issue. After debugging, I noticed that QFileSystemModel _q_fileSystemChanged slot which takes most of the time is still executed on the main UI thread which makes sense. The Questiong is how does the documentation claim than that it will not block the UI. Is there a solution? Am I misunderstanding something?

要复制 -使用QFileSystemDataModel创建一个QTreeView -将根路径设置为"或"/" -在QFileSystemModel _q_fileSystemChanged插槽中设置断点 -加载应用后，展开其中一个驱动器

To repro - Create a QTreeView with QFileSystemDataModel - Set root path to "" or "/" - Set breakpoint in QFileSystemModel _q_fileSystemChanged slot - Expand one of the drives after app loads

问题: -在UI线程上调用该广告位，从而阻止了该应用程序，直到完成为止.

Problem: - The slot is called on the UI thread thus blocking the app until it finishes.

有一些方法可以使文件解析器更快，但是我确实需要在单独的线程上执行并通知何时填充数据并准备好用于QTreeView.

There are ways to make the file parser faster, but it I really need to execute on a seperate thread and notify when the data is populated and ready for QTreeView.

谢谢， Innokenty

Thanks, Innokenty

推荐答案

我认为其原因可能是图标.在_q_fileSystemChanged()插槽内，调用fileInfoGatherer.getInfo()，其中除其他事项外，它解析路径的图标.在当前设计中，QFileIconProvider使用QIcon表示图标，并且QIcon只能在UI线程中使用. QImage似乎是允许在其他线程中使用的唯一类，但我认为在后台线程中使用QImage并将其转换为UI线程中的QIcon可能会花费很多.

I think the reason for this could be the icons. Within the _q_fileSystemChanged() slot fileInfoGatherer.getInfo() gets called which - among other things - resolves the icons for the paths. In it's current design QFileIconProvider uses QIcon to represent icons and QIcon can only be used in the UI thread. QImage seems to be the only class allowed to use in other threads, but I think it may be to expensive to use QImage in the background thread and convert it to an QIcon in the UI thread.

因此QFileIconProvider的平台实现在某些情况下可能会在网络路径上变慢，从而减慢UI主线程的速度.

So it is possible that the platform implementation of QFileIconProvider is slow on network paths under some circumstances and therefore slows down the UI main thread.

我不知道这是否是您的问题的根源，但是至少这应该是在UI线程中调用_q_fileSystemChanged()的原因.

I don't know if this is the source of your problem, but at least this should be the reason why _q_fileSystemChanged() is called within the UI thread.

这篇关于QT:QFileSystemModel _q_fileSystemChanged插槽在与文档相反的UI线程上执行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！