vcl/qt5/QtFilePicker.cxx | 3 ---
1 file changed, 3 deletions(-)
New commits:
commit 54767d6c0e58c8506c899fe290f03b1216846e44
Author: Michael Weghorn <m.wegh...@posteo.de>
AuthorDate: Sat May 10 19:53:01 2025 +0200
Commit: Michael Weghorn <m.wegh...@posteo.de>
CommitDate: Mon May 12 11:49:26 2025 +0200
tdf#166334 qt: Drop extra QDialog::show for file dialog
Both callers of QtFilePicker::prepareExecute take
care of calling either QDialog::exec or QDialog::show
to show the file dialog after calling
QtFilePicker::prepareExecute.
Therefore, calling QDialog::show in
QtFilePicker::prepareExecute in addition is unnecessary,
and also causes issues seen at least sometimes with the kf6 VCL
plugin on X11/XWayland (QT_QPA_PLATFORM=xcb), but not
on Wayland or with the qt6 VCL plugin.
(With kf6, the QFileDialog triggers the native KF6/Plama
file dialog that's maintained in the plasma-integration
git repo.)
Remove the call to QDialog::show from
QtFilePicker::prepareExecute.
Issues that were quite reproducible for me on Debian testing
without this commit in place (and are fixed now):
1) When clicking the save button in the Writer toolbar in
a new document, the Writer window was not always greyed
out when the file dialog opened as a modal dialog.
2) When clicking the PDF export dialog in the Writer toolbar,
the dialog appears for a short time, then another one
(or maybe rather the same one, animated again?) appears
instead.
Case 1) happens in about 50% of the cases, 2) even more
frequently.
The problem described in tdf#166334 that the dialog does
not show up at all is harder to reproduce for me, but hopefully
has the same root cause and is therefore also fixed by
this commit.
It's not exactly clear why the call to QDialog::show
was in QtFilePicker::prepareExecute, but one explanation
might be that it may have been necessary before
commit d79a41a02cd46c50cab08ba1a5d5b213b6843251
Date: Wed Jun 5 14:04:24 2019 +0200
tdf#129071 Qt5 set file picker parent widget
, as the
if (pTransientParent)
{
m_pFileDialog->show();
m_pFileDialog->window()->windowHandle()->setTransientParent(pTransientWindow);
m_pFileDialog->setFocusProxy(pTransientParent);
}
that was in place before that commit made use of the window handle,
which might only have been created when the dialog was actually
shown.
That is no more the case since the above commit however.
Change-Id: I3238aff5be60a33b61f65d36aece74db929f98f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185145
Reviewed-by: Heiko Tietze <heiko.tie...@documentfoundation.org>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.wegh...@posteo.de>
diff --git a/vcl/qt5/QtFilePicker.cxx b/vcl/qt5/QtFilePicker.cxx
index f2a811a1aaf1..788b452f4b2b 100644
--- a/vcl/qt5/QtFilePicker.cxx
+++ b/vcl/qt5/QtFilePicker.cxx
@@ -167,10 +167,7 @@ void QtFilePicker::prepareExecute()
uno::Reference<css::frame::XDesktop>
xDesktop(css::frame::Desktop::create(m_context),
UNO_QUERY_THROW);
-
- // will hide the window, so do before show
m_pFileDialog->setParent(pTransientParent, m_pFileDialog->windowFlags());
- m_pFileDialog->show();
xDesktop->addTerminateListener(this);
}
