QT：QFileSystemModel _q_fileSystemChanged 插槽在 UI 线程上执行，这与文档相矛盾
我的 UI 使用 QTreeView 和 QFileSystemModel 来选择文件夹和文件。 QFileSystemModel 的文档表示文件结构更新是在单独的线程上完成的，这意味着 UI 不会被阻止。然而，对我来说情况并非如此，我无法弄清楚其中的差异以及其他人如何没有遇到这个问题。调试后，我注意到 QFileSystemModel _q_fileSystemChanged 槽占用大部分时间仍然在主 UI 线程上执行，这是有意义的。问题是文档如何声称它不会阻塞 UI。有解决办法吗？我误解了什么吗？
重现 - 使用 QFileSystemDataModel 创建 QTreeView - 将根路径设置为“”或“/” - 在 QFileSystemModel _q_fileSystemChanged 槽中设置断点 - 应用程序加载后扩展驱动器之一
问题： - 该槽在 UI 线程上调用，从而阻塞应用程序直到完成。
有多种方法可以使文件解析器更快，但我确实需要在单独的线程上执行，并在数据填充并准备好用于 QTreeView 时发出通知。
谢谢， 因诺肯蒂
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?
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
Problem:
- The slot is called on the UI thread thus blocking the app until it finishes.
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.
Thanks,
Innokenty
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为造成这种情况的原因可能是图标。在
_q_fileSystemChanged()槽中，fileInfoGatherer.getInfo()被调用，其中包括解析路径的图标。在当前的设计中，QFileIconProvider使用QIcon来表示图标，并且QIcon只能在UI 线程中使用。QImage似乎是唯一允许在其他线程中使用的类，但我认为在后台线程中使用QImage并将其转换为可能会很昂贵UI 线程中的 >QIcon。因此，在某些情况下，
QFileIconProvider的平台实现在网络路径上可能会很慢，从而减慢 UI 主线程的速度。我不知道这是否是问题的根源，但至少这应该是在 UI 线程中调用
_q_fileSystemChanged()的原因。I think the reason for this could be the icons. Within the
_q_fileSystemChanged()slotfileInfoGatherer.getInfo()gets called which - among other things - resolves the icons for the paths. In it's current designQFileIconProviderusesQIconto represent icons andQIconcan only be used in the UI thread.QImageseems to be the only class allowed to use in other threads, but I think it may be to expensive to useQImagein the background thread and convert it to anQIconin the UI thread.So it is possible that the platform implementation of
QFileIconProvideris slow on network paths under some circumstances and therefore slows down the UI main thread.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.