Description: If one hoovers over a slide in the left column slide list Impress shows the slide name like a "tooltip" (black rectangle). However it's not possible to click on it to get to the slide. This is really annoying as those tooltips are shown constantly, for all slides in the list and effectively prevent getting to the chosen slide, I have to carefully pick a place in the list which is not hidden by the tooltip and click there. This is a regression, it used to work fine. Steps to Reproduce: - Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info:
Hello [user's name], Thank you for reporting the bug. Unfortunately I can't reproduce in Version: 6.3.0.0.alpha1+ Build ID: 77ae0abe21f672cf4b7d2e069f1d40d20edc49a7 CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-31_15:33:33 Locale: en-GB (en_GB.utf8); UI-Language: en-US Calc: threaded I see the tooltip doesn't block me from choosing a slide Could you please try to reproduce it with a master build from http://libreoffice.soluzioniopen.com/index.php/daily-version/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Sorry, Hello Michal
I just tested it with an empty presentation just created from a random template in LibreOfficeDev 6.4.0.0.alpha0 on openSUSE 15.1 and the bug is still there. Version: 6.4.0.0.alpha0+ Build ID: f75c2b04785aa05cff3bcd52689feb7400a14e8e CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-06-15_11:49:26 Locale: cs-CZ (cs_CZ.UTF-8); UI-Language: en-US Calc: threaded
Hello Michal, Thanks for reporting this issue. Does it happen if you launch LibreOffice from commandline with SAL_USE_VCLPLUGIN=gtk3 soffice ?
It doesn't happen with gtk4 VCL. The main reason is that the tooltip is below the slide so one can't click on it all (and even elsewhere where tooltips are in the slides like in the master page list if you move the mouse closer to the tooltip it moves away so the pointer never appears right on the tooltip as far as I can tell). [BTW LO didn't have any menu at all when I ran it as suggested]
(In reply to Michal Svec from comment #3) > I just tested it with an empty presentation just created from a random > template in LibreOfficeDev 6.4.0.0.alpha0 on openSUSE 15.1 and the bug > is still there. > > CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde5; > TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: > 2019-06-15_11:49:26 A fix regarding tooltip positioning in kde5 was merged 4 days ago: https://gerrit.libreoffice.org/#/c/74548/ This way the tooltip should now longer follow the mouse, if the mouse is in a specified help area. That help area used to be ignored, so that might explain your bug report. At least I can't see any problem with the slide list on master, but it might be a different problem. Would be nice if you can re-test with a current build.
(In reply to Jan-Marek Glogowski from comment #6) > Would be nice if you can re-test with a current build. Well, I could try, but the latest daily is from Jun/15 which is what I used. At least that's what I got from the page referenced in comment #1.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Michal Svec from comment #7) > (In reply to Jan-Marek Glogowski from comment #6) > > Would be nice if you can re-test with a current build. > > Well, I could try, but the latest daily is from Jun/15 which is what I used. > At least that's what I got from the page referenced in comment #1. Hah - seems after almost two weeks there is now an update from 2019-06-27_16.34.10. Whatever is the problem with infrastructure... https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF/
Indeed, it works much better. Not 100% though, one can still click on the tooltip if the mouse pointer is moved faster than the tooltip moves away and still have the same issue, but it happens less often. I guess we will see in real life how does it behave. Can we please have the fix backported to the stable release? At least 6.3 would be nice, I'm not sure whether we need it for 6.2 though.
(In reply to Michal Svec from comment #10) > Indeed, it works much better. Not 100% though, one can still click on the > tooltip if the mouse pointer is moved faster than the tooltip moves away > and still have the same issue, but it happens less often. I guess we will > see in real life how does it behave. This is completely handled by Qt. I'm not sure there is anything I can do to improve the situation further without a huge effort. The API just has a text, the point of interest and a help area. Quoting the docs: "The tool tip will be shown with a platform specific offset from this point of interest.", with "point of interest" being the mouse position. All the hiding and movement is completely transparent for LO. > Can we please have the fix backported to the stable release? At least 6.3 > would be nice, I'm not sure whether we need it for 6.2 though. That fix is already in 6.4 (https://gerrit.libreoffice.org/#/c/74548/) and 6.3 (https://gerrit.libreoffice.org/#/c/74571/). Fixing that in 6.2 would be easy, if this doesn't depend on other stuff. I pushed a backported patch for 6.2 (https://gerrit.libreoffice.org/#/c/74854/), but I can't test it. Let's see what others say about it.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/9ed060d38fd8dc85bebccbc735bce8bf66a89df4%5E%21 tdf#125606 Qt5 directly show tooltips + respect the help area It will be available in 6.2.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks!