Summary: | URL tool tips should have a delay | ||
---|---|---|---|
Product: | [Unmaintained] rekonq | Reporter: | Christoph Feck <cfeck> |
Component: | general | Assignee: | Andrea Diamantini <adjam7> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | CC: | dev+kde |
Priority: | NOR | ||
Version: | latest git snapshot | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Christoph Feck
2010-05-27 00:29:07 UTC
What would be the practical use of that? Personally, I consider this a negative feature, because it makes the user wait needlessly. When I hover over a series of links to know their target address, such a delay would mean I had to stop mouse movement over every link. OTOH, in the bug that you reference, a delay for tab previews is OK because it is much more obstrusive and often not the goal when you hover the mouse over a tab (most times I just want to click a tab and don’t need the popup). It should work like any other tooltips work. There is only an initial delay. Once the tooltips are shown, moving to a different target displays the next tooltip without a delay. We are divided in the two positions, someone thinking like Christoph and someone else like Frank. That's because things are not moving about this. Anyway, I received a patch implementing a "general" delay (not just on the first link) and I found it quite irritating. Moreover someone else noticed that statusbar link suggestions are not delayed, concluding that we did really not implement a tooltip, but an "escamotage" to have statusbar infos saving statusbar space for navigation. To say it all, here discussion stopped and we started playing with other code ;) Christoph, the flaw in your last argument is that it is *not* a standard tooltip as you would get, for example, if you stay on a toolbar button with your mouse. Such tooltips are delayed by default because they are meant as an auxiliary source of help and would get in the way if you don’t need such help (which most often is the case), whereas the popups we are talking about here are always relevant, because they change from link to link. Coincidentally, I’ve just had a situation in Firefox that shows the problem with a delayed popup: I looked at a site and wanted to know where a link was going. So I looked at the window corner and moved the mouse vertically over the link. Nothing showed up. Why? Because before the delay timed out, the mouse was already past the link. “Why don’t you put the mouse on the link and then look down?” you might ask. Well, with one link it’s a fair question, but what if I wanted to see the general scheme of linking for a list of links? I don’t know why such a delay was implemented in the first place, the only thing I can think of is to reduce distracting flicker from popups in the corner when you move your mouse over the page randomly, and thusly move it over links. Fair enough, but 200ms is definitely too much, even for this. > the only thing I can think of is to reduce distracting flicker from popups Exactly. > but 200ms is definitely too much Possibly. You could experiment with different delays once it's implemented. Our experiments denoted that, having a delay, in pages with a lot of links, fast moving the pointer, then stopping in blank spaces, then fast moving again let the association link-pointer more difficult. So, we are for maintaining a bit of flickering. |