Bug 73327 - Other: StartCenter: tooltips appear instantly on last used files in startcenter
Summary: Other: StartCenter: tooltips appear instantly on last used files in startcenter
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected) rc
Hardware: Other All
: low enhancement
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Reported: 2014-01-06 16:50 UTC by retired
Modified: 2015-11-27 22:39 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description retired 2014-01-06 16:50:39 UTC
Steps to reproduce:
1. Open StartCenter in or newer
2. Hover over recent documents displayed in startcenter

Current behavior:
The tooltip with the file URL instantly shows up for the document hovered over. This destroys the otherwise nice and clean UI of the startcenter. Tooltips  vary in length etc. It just doesn't look good.

Expected behavior:
I doubt many users do need the file URL. I suggest delaying the display of the tooltips around 3 seconds. If you really need the file URL it's fair to wait that short amount of time. For the rest and majority of the users that then means a much better UX when working with the startcenter.

Talked to cloph about this in IRC and he said maybe that time is taken from the system since it matches the delay in gnome apps. I myself am using OSX here.
Operating System: Mac OS X
Version: rc
Comment 1 retired 2014-01-06 17:12:27 UTC
Maybe uncoupling display of tooltips in LO and display of tooltips displayed in startcenter would be a solution?

I like tooltips in LO, I hate them in startcenter. Currenty if I disable them they are competely gone. Not sure what a good way to deal with this is. Just had an interesting discussion with jmadero. He argued that many people with a naming scheme that allows for files with identical names are dependent on the file URL tooltips.

Maybe if those would be displayed permanently below the file (where thers still is tons of white unused space) would make for a calmer UI and solve the issue?
Comment 2 retired 2014-01-06 19:05:01 UTC
LO doesn't use GTK timeout settings, but just happens to be that LO's default is the same (or very similar) to the 500ms that is default in GTK			http://opengrok.libreoffice.org/xref/core/vcl/source/app/settings.cxx#1246 I guess that's where it is hardcoded.
Comment 3 retired 2014-01-10 12:11:54 UTC
If anybody knows who from UX to ping about this, would be great to get some feedback on this, please add them to cc:
Comment 4 Adolfo Jayme Barrientos 2014-01-10 12:31:31 UTC
LibreOffice should exactly match the timeout of the platform it’s running on. Immediate tooltips are annoying, and too-delayed ones aren’t useful.

If this timing can’t be matched, I suggest using a default value of 1.5 seconds.
Comment 5 Jean-Baptiste Faure 2014-01-11 16:32:16 UTC
I disagree in the case of the recent files area in the StartCenter. Indeed tooltip is the only way to get the full path of a recent file. User will want an instant answer from the UI.
So I prefer the current behavior.

Best regards. JBF
Comment 6 retired 2014-12-16 08:36:06 UTC
NOTABUG. This is just working as expected. If users do use tooltips, they likely want them to behave the standard way. Anybody annoyed by tooltips will likely disable them.
Comment 7 Yousuf Philips (jay) (retired) 2014-12-16 13:05:22 UTC
I happened across this annoying behaviour a few days back and felt the delay should be longer than it currently is, as i see no delay when moving from one file to the next.

(In reply to foss from comment #6)
> Anybody annoyed by tooltips will likely disable them.

Most users dont change the default settings in LO, so even if they are annoyed with it, they are not likely to change it. Also if they disable it in Tools > Options > General, that disables it in the start center as well, where it is quite needed.
Comment 8 retired 2014-12-16 20:42:06 UTC

V Stuart: Thoughts?

If UX / Design agree on this, would be great to adjust the default for this specific location in LO.
Comment 9 V Stuart Foote 2014-12-16 21:22:09 UTC
(In reply to foss from comment #8)
> V Stuart: Thoughts?
> If UX / Design agree on this, would be great to adjust the default for this
> specific location in LO.

Actually, I think the timing is about correct -- there is a noticeable pause at each UI action: 1) mouse over, 2) object focus, 3) tool-tip pop-up. But, assume it would be trivial to put a delay in at any of those UI actions. Although I don't really see it as improving the UX.

However, we are missing tool-tip pop-up for keyboard navigation, only the file name is exposed to AT, no way to obtain path--an a11y issue. But, the timing in that regard would not have to change.

Setting NEW and back to UX-advise for any Hangout decision.

But, I'll recommend for Resolved Wontfix unless a developer has spare cycles and really wants to poke at this. Perhaps in the context of doing the mouse over module filtering enhancement of bug 80934#c3--mouse-over timings and GUI refresh would become significant to UX at that point.

Another aspect that would be nice, if this is refactored, would be to make the tool-tip path available to copy/paste--but that is a different issue.
Comment 10 Adolfo Jayme Barrientos 2014-12-17 06:01:00 UTC
> If UX / Design agree on this, would be great to adjust the default for this
> specific location in LO.

UX feedback was already given to this bug in comment 4. Do we need to discuss that further?
Comment 11 retired 2014-12-17 06:47:19 UTC
Let's evaluate if 1,5s are possible. If easily doable could be a nice improvement. If this required tons of work > Wontfix.

TBD on next design meeting (today?).
Comment 12 steve 2015-11-27 22:39:23 UTC
Let's close as worksforme