Download it now!
Bug 125606 - Slide list "names" get in a way so one can't click on the slides
Summary: Slide list "names" get in a way so one can't click on the slides
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.4.0 target:6.3.0.1 target:6.2.6
Keywords:
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2019-05-31 07:49 UTC by Michal Svec
Modified: 2019-07-01 08:03 UTC (History)
3 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 Michal Svec 2019-05-31 07:49:36 UTC
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:
Comment 1 Usama 2019-06-16 03:07:35 UTC
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
Comment 2 Usama 2019-06-16 03:08:31 UTC
Sorry, Hello Michal
Comment 3 Michal Svec 2019-06-26 08:13:44 UTC
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
Comment 4 Xisco Faulí 2019-06-26 08:21:30 UTC
Hello Michal,
Thanks for reporting this issue.
Does it happen if you launch LibreOffice from commandline with SAL_USE_VCLPLUGIN=gtk3 soffice ?
Comment 5 Michal Svec 2019-06-26 08:33:55 UTC
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]
Comment 6 Jan-Marek Glogowski 2019-06-26 18:07:45 UTC
(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.
Comment 7 Michal Svec 2019-06-27 12:25:07 UTC
(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.
Comment 8 QA Administrators 2019-06-28 03:00:25 UTC Comment hidden (obsolete)
Comment 9 Jan-Marek Glogowski 2019-06-28 06:56:19 UTC
(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/
Comment 10 Michal Svec 2019-06-28 07:46:53 UTC
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.
Comment 11 Jan-Marek Glogowski 2019-06-28 16:07:15 UTC
(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.
Comment 12 Commit Notification 2019-06-29 07:38:36 UTC
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.
Comment 13 Michal Svec 2019-07-01 08:03:43 UTC
Thanks!