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).
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
(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?
> 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 ;)
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.
Let's close this as fixed and see if anyone complains
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
*** Bug 124432 has been marked as a duplicate of this bug. ***
*** Bug 124957 has been marked as a duplicate of this bug. ***
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?
(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.
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?
(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.
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
(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
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
> 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.
Is there a bugzilla area for the "Visual Class Library"?
(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.)
(In reply to AtesComp from comment #17) > Is there a bugzilla area for the "Visual Class Library"? Yes, that's the "graphics stack" component.
*** Bug 128842 has been marked as a duplicate of this bug. ***
Exactly the same problem/behavior suddenly came up on my OpenSUSE 15.1 some days/weeks ago... Version: 6.3.3.2.0+ Build-ID: 30(Build:2) CPU-Threads: 4; BS: Linux 4.12; UI-Render: Standard; VCL: kde5; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded
It's https://bugzilla.opensuse.org/show_bug.cgi?id=1164885 there...
(In reply to Peer Heinlein from comment #22) > It's https://bugzilla.opensuse.org/show_bug.cgi?id=1164885 there... Reading that bug report and those linked from there, it's the reason as mentioned in comment 6 (too old Qt version) and it seems that OpenSUSE is taking care of this (discussing whether to force another VCL plugin until new enough Qt is available in OpenSUSE).