擅长:python、mysql、java
<p>我自己也一直在调查这个问题,对“只使用非本机对话”一点不满意。我一直在KDE平台文件对话框实现中进行黑客攻击,并且已经(卡住)了我想要的东西。在</p>
<p>我发现的唯一附加点是在对话框实际显示之前;在此之前,似乎没有办法知道实际的父窗口小部件。但我们可以:</p>
<ul>
<li>找到父级QWidget(从父级<em>QWindow</em>)</li>
<li>从中,获得(第一个)(用户端)QFileDialog实例</li>
<li>如果父QWidget有一个布局,用我们自己的对话框替换找到的QFileDialog实例</li>
<li>保存原始用户端QFileDialog实例</li>
<li>在dtor中,恢复布局中的原始QFD,或对其调用deleteLater()(并将其设置为NULL,以防操作导致对dtor的递归调用)。在</li>
</ul>
<p>故障:
-对话框可能以2组“确定/取消”等按钮结束
-如果不是,这些按钮实际上可能只关闭嵌入的QFD,而不是封闭的对话框(见上面链接的python示例)
-调整大小有效,但saveSize/restoreSize机制不起作用
-所有信号都没有正确连接(Scribus打开文件对话框中的预览对选择文件没有反应)。不过,打开文件确实管用。在</p>
<p>此BKO票据的完整补丁:
<a href="https://bugs.kde.org/show_bug.cgi?id=404833#c15" rel="nofollow noreferrer">https://bugs.kde.org/show_bug.cgi?id=404833#c15</a></p>
<p>显然,这只对黑客和可以发布自己的平台主题插件(KDE平台文件对话框的来源)的软件有用。幸运的是,这些插件往往相对较小。在</p>