Bug Hunting Session
Bug 119719 - kde5: Impress presentation doesn't properly use dual-monitor
Summary: kde5: Impress presentation doesn't properly use dual-monitor
Status: VERIFIED NOTOURBUG
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-08-30 06:19 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.
Comment 13 AtesComp 2019-08-29 02:36:19 UTC
Well, FIXED is a little strong.

The workaround is to set SAL_USE_VCLPLUGIN=gtk3 globally (or per user, or whatever).

For my system, no other setting works for a dual monitor setup.  They either don't display anything (even before F5) or only display the presenter view on the main screen (nothing on the second screen, swapping doesn't work either and actually makes it worse).

<rant>
REALLY!!! You don't know how to check the QT version during runtime?!?!?!

    const char *qt_version = qVersion();

I found that in like 5 seconds on the innertubes!

    A discrepancy between the compile time and runtime version can be detected
    by comparing the qVersion() output to the QT_VERSION_STR. If different,
    you can then decide to do further testing to determine whether things will
    work.

    if(strcmp(qt_version, QT_VERSION_STR) != 0)
    {
      // version mismatch...
      // here you could verify whether just the patch is different
      // or the full blown major/minor versions
      ...
    }

That's about as clean as it gets.
</rant>

Version: 6.3.0.4
Build ID: 1:6.3.0-0ubuntu0.18.04.1~lo2
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: CL
Comment 14 Michael Weghorn 2019-08-29 06:25:48 UTC
(In reply to AtesComp from comment #13)
> Well, FIXED is a little strong.

You're right, I've changed that to NOTOURBUG, since the underlying bug is/was in Qt.


> 
> The workaround is to set SAL_USE_VCLPLUGIN=gtk3 globally (or per user, or
> whatever).
> 
> For my system, no other setting works for a dual monitor setup.  They either
> don't display anything (even before F5)

That sounds like another bug which I haven't seen so far. Feel free to file a separate bug report, giving clear steps to reproduce.

>  or only display the presenter view
> on the main screen (nothing on the second screen, swapping doesn't work
> either and actually makes it worse).
> 
> <rant>
> REALLY!!! You don't know how to check the QT version during runtime?!?!?!
> 
>     const char *qt_version = qVersion();
> 
> I found that in like 5 seconds on the innertubes!
> 
>     A discrepancy between the compile time and runtime version can be
> detected
>     by comparing the qVersion() output to the QT_VERSION_STR. If different,
>     you can then decide to do further testing to determine whether things
> will
>     work.
> 
>     if(strcmp(qt_version, QT_VERSION_STR) != 0)
>     {
>       // version mismatch...
>       // here you could verify whether just the patch is different
>       // or the full blown major/minor versions
>       ...
>     }
> 
> That's about as clean as it gets.
> </rant>

Thanks for looking into this! I'll be happy to review a patch on Gerrit that implements a proper check, so please feel free to submit one (s [1]).

What needs to be taken into account is that - to my knowledge - the LibreOffice module taking care of loading VCL plugins does not link against Qt and other toolkit libraries (and it IMHO shouldn't), so my guess would be that you can't just use the 'qVersion()' macro as is without changing the underlying architecture/concept of how VCL plugin loading currently works.
I didn't spend much time on further investigating it yet, though, and would be happy to be proved wrong. :-)


As a side note, instead of setting SAL_USE_VCLPLUGIN=gtk3, you can also just uninstall the '...-kde-integration' package if you're using the TDF provided packages, or otherwise try to convince your distro to backport the relevant patch for their packaged Qt version (or package a new enough one). For distro-provided LibreOffice packages, I also see it somewhat in the responsibility of the distro maintainers to make sure the packaged software and library versions interact nicely with each other...

[1] https://wiki.documentfoundation.org/Development/gerrit
Comment 15 Katarina Behrens (CIB) 2019-08-29 12:43:11 UTC
Thanks for explaining Qt to us, who would've guessed otherwise :D

Minimum required Qt verson is 5.6 atm. This bug -- slideshow in dual screen setup, so a small subset of all office functionality -- is so far the only one that would require newer Qt. 

Disabling the entire Qt/KDE/Plasma integration for all Ubuntu LTS users because of one bug sounds like a bad trade-off to me, but different people (and distro maintainers) can have different opinions.

Otherwise things are not as simple as they might seem, exactly as michaelweghorn says. He knows what he is talking about
Comment 16 AtesComp 2019-08-29 21:48:06 UTC
> That sounds like another bug which I haven't seen so far. Feel free to file a
> separate bug report, giving clear steps to reproduce.

I previously did...bug 124432 was marked as a duplicate.  It has steps on all configurations and tests I performed.  The issues are essentially the same now as it was then.

I'm glad my "rant" was taken well as it was meant well.  I know it's a "Captain Obvious" moment...and there is more to it than just a simple check.  Text just doesn't do my dry humor justice ;)

> What needs to be taken into account is that - to my knowledge - the LibreOffice
> module taking care of loading VCL plugins does not link against Qt and other
> toolkit libraries (and it IMHO shouldn't), so my guess would be that you can't
> just use the 'qVersion()' macro as is without changing the underlying
> architecture/concept of how VCL plugin loading currently works.
> I didn't spend much time on further investigating it yet, though, and would be
> happy to be proved wrong. :-)

Without looking into the code further, I don't know either.  However, the VCL plugin system implicitly depends on the display system the plugin requires. For this architecture, I see 3 choices:
1. Each VCL plugin "should" report its dependent run time and compile time system versions at load time,
2. The plugin should make the decision and adjust its own behavior when running a system version below the expected version,
3. The plugin should report back to the VCL loader that it doesn't have the expected version to run the plugin or a version mismatch.
For 1 and 3, this gives the VCL loader module a chance to make a decision, i.e., continue to use it or try another VCL plugin.  Right now, it seems like it just blindly tries to use whatever its told to use.  Theoretically, with the right version checking available, it could test each VCL plugin to see which systems are available.

Again, obvious...just don't depend on the selected VCL plugin having all the features needed by the app...make versioning/system checks a requirement.

> you can also just uninstall the '...-kde-integration' package

Most users will have no clue what the issue is and just walk away saying "Libreoffice is broke."

> Minimum required Qt version is 5.6 atm. This bug -- slideshow in dual screen
> setup, so a small subset of all office functionality -- is so far the only
> one that would require newer Qt.

True, but perspective is KING!  Small in terms of a programmers perspective of office functionality.  HUGE is terms of a user's experience.  Impress is meant to be shown...the primary feature is to present a presentation.  Dual screen is the standard.  Few will crowd around a laptop screen to see a presentation. 
 Please don't undersell the importance of this bug.
Comment 17 AtesComp 2019-08-30 00:15:36 UTC
Is there a bugzilla area for the "Visual Class Library"?
Comment 18 Michael Weghorn 2019-08-30 06:18:17 UTC
(In reply to AtesComp from comment #16)
> > That sounds like another bug which I haven't seen so far. Feel free to file a
> > separate bug report, giving clear steps to reproduce.
> 
> I previously did...bug 124432 was marked as a duplicate.  It has steps on
> all configurations and tests I performed.  The issues are essentially the
> same now as it was then.

Just saw your update there and it seems everything is fine with kde5 and gtk3 on Ubuntu 19.04 now?

> I'm glad my "rant" was taken well as it was meant well.  I know it's a
> "Captain Obvious" moment...and there is more to it than just a simple check.
> Text just doesn't do my dry humor justice ;)

:)

> Without looking into the code further, I don't know either.  However, the
> VCL plugin system implicitly depends on the display system the plugin
> requires. For this architecture, I see 3 choices:
> 1. Each VCL plugin "should" report its dependent run time and compile time
> system versions at load time,
> 2. The plugin should make the decision and adjust its own behavior when
> running a system version below the expected version,
> 3. The plugin should report back to the VCL loader that it doesn't have the
> expected version to run the plugin or a version mismatch.
> For 1 and 3, this gives the VCL loader module a chance to make a decision,
> i.e., continue to use it or try another VCL plugin.  Right now, it seems
> like it just blindly tries to use whatever its told to use.  Theoretically,
> with the right version checking available, it could test each VCL plugin to
> see which systems are available.
> 
> Again, obvious...just don't depend on the selected VCL plugin having all the
> features needed by the app...make versioning/system checks a requirement.

What the module currently does is basically a 'dlopen()' on the VCL libraries in a given order (depending on desktop environment), and the first one for which this succeeds is used.
If you plan to change such a fundamental thing, I suggest to discuss on the development mailing list first.

> 
> > you can also just uninstall the '...-kde-integration' package
> 
> Most users will have no clue what the issue is and just walk away saying
> "Libreoffice is broke."

True. However, as mentioned, I see how distro maintainers would usually take care of such issues for their packaged versions, and "ordinary" users might still try "let's see whether it works on latest Ubuntu", which has a sufficiently new version of Qt. Sure, it's not perfect, but I don't see how LibreOffice would simply "fix" that, given the bug is in Qt.

> 
> > Minimum required Qt version is 5.6 atm. This bug -- slideshow in dual screen
> > setup, so a small subset of all office functionality -- is so far the only
> > one that would require newer Qt.
> 
> True, but perspective is KING!  Small in terms of a programmers perspective
> of office functionality.  HUGE is terms of a user's experience.  Impress is
> meant to be shown...the primary feature is to present a presentation.  Dual
> screen is the standard.  Few will crowd around a laptop screen to see a
> presentation. 
>  Please don't undersell the importance of this bug.

I mostly agree. Yet, the bug is not inside LibreOffice, and it has been fixed, so I'd rather spend my time on fixing other bugs - that are also HUGE in term of (other?) user's perspective. And it seems, bugs have a strong tendency to be HUGE in the eyes of the person who reported it. :-)

(With that said, I'd also not deploy LibreOffice with kde5/kf5 VCL plugin and unchanged Qt 5.9 due to this bug in an enterprise environment. However, I'd backport the Qt fix instead of changing LibreOffice.)
Comment 19 Michael Weghorn 2019-08-30 06:19:07 UTC
(In reply to AtesComp from comment #17)
> Is there a bugzilla area for the "Visual Class Library"?

Yes, that's the "graphics stack" component.