Bug 119719 - kde5: Impress presentation doesn't properly use dual-monitor
Summary: kde5: Impress presentation doesn't properly use dual-monitor
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Katarina Behrens (CIB)
URL:
Whiteboard: target:6.2.0
Keywords:
: 124432 124957 (view as bug list)
Depends on:
Blocks: KDE Slide-Show Multimonitor
  Show dependency treegraph
 
Reported: 2018-09-06 08:47 UTC by Michael Weghorn
Modified: 2019-05-27 06:46 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Weghorn 2018-09-06 08:47:09 UTC
version: master build as of commit 1f5698ba8b62e62999b0efb363916a91bdd54c94
VCL: kde5 on X11 (the gtk3 VCL plugin e.g. works fine)
platform: Debian testing, Plasma 5 desktop

Steps to reproduce:

0) use a computer that has two screens attached
1) Open any presentation with Impress, e.g. use https://bugs.documentfoundation.org/attachment.cgi?id=144709
2) switch to presentation mode by pressing 'F5'

Result:

1) Already handled in bug 119178: The screen turns white. The presentation starts when clicking into the white area using the mouse.

2) Both presenter view and the full-screen presentation are on the same screen.

This bug report is about 2), since there's a separate bug report for 1).

Expected result:

Presenter view and the full-screen slides are shown on different screens (presenter view on primary screen).
Comment 1 Katarina Behrens (CIB) 2018-10-25 15:50:20 UTC
If someone has a dual screen setup and possibility to build LibO themselves, here https://gerrit.libreoffice.org/#/c/62351/ are 2 versions of one patch

1st version works for me only in GNOME, KDE Plasma still forces both fullscreen windows to one screen. I suspect this is a Plasma bug and I tried to solicit some help from Plasma developers. They suggested a workaround bypassing WM but even with that I can't achieve true fullscreen

2nd one works for me in general but the approach it uses is a hack and I'm not so very happy w/ it.

I'd appreciate some feedback on this
Comment 2 Michael Weghorn 2018-10-25 17:08:25 UTC
(In reply to Katarina Behrens (CIB) from comment #1)
> If someone has a dual screen setup and possibility to build LibO themselves,
> here https://gerrit.libreoffice.org/#/c/62351/ are 2 versions of one patch
> 

Interestingly, both versions work for me in a quick test on Debian testing and Plasma running under X11 (with following package versions: plasma-desktop 4:5.13.5-1+b1, kwin-x11 4:5.13.5-1+b1, libqt5widgets5 5.11.2+dfsg-3).

What version of Plasma and Qt are you using?
Comment 3 Katarina Behrens (CIB) 2018-10-26 08:54:36 UTC
> Interestingly, both versions work for me in a quick test on Debian testing
> and Plasma running under X11 (with following package versions:
> plasma-desktop 4:5.13.5-1+b1, kwin-x11 4:5.13.5-1+b1, libqt5widgets5
> 5.11.2+dfsg-3).
> 
> What version of Plasma and Qt are you using?

Plasma 5.12.6
libqt5 5.9.6

Okay so let's run w/ patch 1 and blame any issues on old version of Plasma ;)
Comment 4 Commit Notification 2018-10-26 18:11:08 UTC
Katarina Behrens committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=140434a7677946020bb2c6db9ed3afe8998ee7d0

tdf#119719: Move the window to the requested screen

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 Katarina Behrens (CIB) 2018-11-01 09:02:50 UTC
Let's close this as fixed and see if anyone complains
Comment 6 Michael Weghorn 2018-12-15 00:37:49 UTC
For the record: Qt 5.10 is needed for this to work, and the commit in the qtbase repository from which on this works (in conjunction with the LO fix) is this one:

commit d7a9e08f0ada36ad8ad44651f27a76c9c74e3428 (HEAD)
Author: Morten Johan Sørvig <morten.sorvig@qt.io>
Date: Wed Apr 19 11:19:19 2017 +0200

 Make QWindow::setVisible() work for widgets
Comment 7 Michael Weghorn 2019-04-03 16:49:03 UTC
*** Bug 124432 has been marked as a duplicate of this bug. ***
Comment 8 Michael Weghorn 2019-04-25 14:57:56 UTC
*** Bug 124957 has been marked as a duplicate of this bug. ***
Comment 9 Horst Schirmeier 2019-05-03 12:02:10 UTC
Although I can confirm that this bug is gone with Qt 5.10, I wouldn't consider this bug to be "fixed".

For example, Ubuntu 18.04 LTS will be around for quite a while, and has an older Qt version (5.9.5).  Debian stable still has Qt 5.7.1.  With LO 6.1, presentations worked well with Qt 5.9.5; so I'd still consider it a regression bug that LO 6.2's presentation mode doesn't work anymore with the most recent Ubuntu LTS release.  Isn't it possible to restore the code portion that worked with Qt 5.9.5?
Comment 10 Michael Weghorn 2019-05-03 12:12:17 UTC
(In reply to Horst Schirmeier from comment #9)
> Isn't it possible to restore the code
> portion that worked with Qt 5.9.5?

The code is still there, it's just that another code path (kde5 VCL plugin) is chosen by default.
You can choose to use the previous behaviour by setting the environment variable SAL_USE_VCLPLUGIN=kde4 for LibreOffice 6.2 or use e.g SAL_USE_VCLPLUGIN=gtk3_kde5 instead.

Alternatively, you can choose to remove the kde integration packages until you have a system with a new enough Qt version by running

  sudo apt purge libobasis6.2-kde-integration

if you're using the TDF-provided packages.

I hope that helps.
Comment 11 Horst Schirmeier 2019-05-03 13:38:08 UTC
Thank you for the workaround.  But while *I* could certainly use it (if I hadn't already upgraded to a distribution with Qt >=5.10), I guess many Ubuntu LTS users out there cannot and will simply experience a bad day after installing LO 6.2.  

Maybe the workaround could be automated when Qt <5.10 is detected?
Comment 12 Michael Weghorn 2019-05-27 06:46:32 UTC
(In reply to Horst Schirmeier from comment #11)
> Maybe the workaround could be automated when Qt <5.10 is detected?

I currently can't come up with a clean and easy way how to do this.