Bugzilla – Full Text Bug Listing
| Summary: | [Hover] Fix tooltip life cycle | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Rafael Chaves <eclipse> | ||||
| Component: | Editor | Assignee: | Project Inbox <orion.editor-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | curtis.windatt.public, emoffatt, gheorghe | ||||
| Version: | 4.0 | ||||||
| Target Milestone: | 8.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 450152, 453226 | ||||||
| Attachments: |
|
||||||
|
Description
Rafael Chaves
Maybe we need to use the blame behavior here: if you want to keep the annotation up, you would mouse over the popup. This would keep it up until you move the mouse out of the popup. On that note, a workaround I figured out after reporting this is that if I click the hover, it will stick around (until click elsewhere). Eric is looking at improving the focus/fade behaviour in 8.0 Created attachment 249010 [details]
Markup explaining the eclipse tooltip handling
The big difference between what eclipse does and what we currently do is that in eclipse there are no 'show' or 'hide' timers, everything is based off of a 'hover' event. Also the life-cycle is simpler...on a hover:
1) Am I inside the context box...
yes -> no-op,
no -> see if there's new hover info to show
no -> no-op
yes -> replace the existing hover
We'll need the ability for the returned hover 'info' to define the context box; likely by returning an offset range.
The one other thing we need is the ability to define the define the 'anchor' we want to use to align the tooltip with it's context box (in the picture it'd be 'below').
Two other things to note: - The text size is smaller not larger than the code's text - The tooltip changes when you place the cursor inside it (i.e. it grows scroll bars and some extra command buttons...but doesn't give it keyboard focus). This is good for discoverability... We've been doing some work on this in a branch called 'TooltipLifeCycle'... I've committed the first pass of this to master: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=67f81f36e4af4bf3d6f664b932976386068f0b5b - matches eclipse mechanics more closely - still needs work on placement and sizing (see bug 453226) kk, I've done some more work on this, mostly hiding the tooltip: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=2bd7d6b1ab1d9de328e2b6d6d720b61484174544 - on a model change (i.e. quickfix) (Also allows me to remove the 'click' listeners on qf buttons) - on a keypress (user's typing, don't get in the way) - on a scroll (basically prevents a hover unless the mouse has really moved) This commit also fixes a regression to the hover which was allowing hover events to fire when over the tooltip itself... OK, here;s a start to the handling for rulers: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=afd05c27e005aa68999f148f75cf4c809fc03e3f this just ensures that we don't (re)show the tooltip until the mouse moves after a click on the ruler... Marking as FIXED in 8.0. While there are still tweaks to the sizing of the boxes, the original issue of the hovers fading out on delay is fixed. |