QT：QFileSystemModel _q_fileSystemChanged插槽在与文档相矛盾的UI线程上执行

我的用户界面使用QTreeView和QFileSystemModel来选择文件夹和文件。 QFileSystemModel的文档说文件结构更新是在单独的线程上完成的，这意味着UI不会被阻塞。然而，对我来说情况并非如此，我无法弄清楚这种差异以及其他人没有遇到这个问题。在调试之后，我注意到大部分时间的QFileSystemModel _q_fileSystemChanged插槽仍然在主UI线程上执行，这是合理的。问题是文档如何宣称它不会阻止用户界面。有解决方案吗？我误解了什么吗？QT：QFileSystemModel _q_fileSystemChanged插槽在与文档相矛盾的UI线程上执行

要REPRO - 与QFileSystemDataModel 创建QTreeView则 - 设置根路径 “” 或 “/” - 设置断点QFileSystemModel _q_fileSystemChanged时隙 - 展开驱动器的一个应用程序加载后

问题： - 插槽在UI线程上调用，从而阻止应用程序，直到完成。

有办法让文件解析器更快，但是我真的需要在单独的线程上执行并通知数据何时填充并准备好用于QTreeView。

感谢， Innokenty

来源

2010-10-29 Innokenty

当不用断点调试时，你的应用程序实际上是否冻结？ – 2010-10-29 21:01:06

是的。它在映射网络共享上大部分和非常显着，因为它必须查询每个项目。对于映射驱动器和常规驱动器，代码路径是相同的。 – Innokenty 2010-10-29 21:12:28

我想这样做的原因可能是图标。在_q_fileSystemChanged()槽fileInfoGatherer.getInfo()被称为哪些 - 除其他外 - 解决路径的图标。在当前的设计中，QFileIconProvider使用QIcon来表示图标，并且QIcon只能在UI线程中使用。 QImage似乎是允许在其他线程中使用的唯一类，但我认为在后台线程中使用QImage并将其转换为UI线程中的QIcon可能会很昂贵。

因此，在某些情况下，网络路径上的QFileIconProvider平台实现可能会很慢，因此会降低UI主线程的速度。

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

来源

2010-10-31 09:48:00

QT：QFileSystemModel _q_fileSystemChanged插槽在与文档相矛盾的UI线程上执行

回答

相关问题