The presentation minimizer dialog calls setVisible before execute.
This results in the dialog being shown before setting the modality
in execute. And this triggers a bug in the Qt / Xcb stack (gtk is
fine because it directly uses XSendEvent to change the state).

The result is an unmapped, modal dialog window: it's invisible and
blocks the GUI. Qt believes it's show; isVisible() returns true.

And my ~/.xsession-errors shows a "qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow) ... major code: 18 (ChangeProperty)" with an
invalid resource id, according to 'xwininfo -tree -root'.
You can find the window resource of the minimizer by its name in
the full root tree and its unmapped state with 'xwininfo -id'.

I originally thought of a Scheduler bug so enabled debug output
for it. This is already responsible for a delay long enough to
prevent the bug often. Same for doing an additional hide() and
show() sequence. In the end I went with a fixed delay, but that
is just a guess. In theory we could check the mapped state via
Xlib in Qt's show event and manually map it using XMapWindow and
the winId...

I also noted that the minimizer leaks, as there are multiple new
presenter resources after each show and hide...

Change-Id: I2060918aa9c63d385ebb2ffee9e7a3e4196ea766
Reviewed-on: https://gerrit.libreoffice.org/73462
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>