Community
Participate
Working Groups
Build ID: I20081202-1812 Steps To Reproduce: 1. Create a tooltip 2. Try to move the cursor into it (e.g. to access a widget inside). 3. The tooltip disappears. - Alternatively - 1. Create a tooltip and move it so when it appears it's underneath the cursor. 2. Hover over a user interface element - the tooltip appears, preventing you from interacting with the widget you were hovering over. More information: This was discovered from Bug 257903. In it, I have a CheckboxTreeViewer that when you hover over a tree item, a tooltip appears, with links in it. The two problems described above occur.
Created attachment 119839 [details] Snippet to demonstrate problem This snippet demonstrates the problem - javadoc comments explain how to run and use to simulate error.
Created attachment 119841 [details] Patch to allow the cursor to enter the tooltip This patch adds two methods to the JFace ToolTip class: setAllowCursorToEnter(boolean) and isAllowCursorToEnter(). Setting allowCursorToEnter to false (the default value) causes the default behaviour. Setting it to true allows the user to move his cursor into the tooltip. What it does is add a condition to the shouldHideToolTip method that checks if the allowCursorToEnter field is true and if the cursor is between its initial location and the tooltip. If so, it allows the tooltip to remain visible, thus allowing the cursor to enter the tooltip. Once the cursor is inside the tooltip, a listener on the tooltip itself will cause the tooltip to disappear should the cursor leave the tooltip at all - i.e. this new functionality only keeps the tooltip open when the cursor is approaching it, and the old behaviour resumes once the cursor reaches the tooltip.
Boris: we're proposing adding this as new API, so we'd like to run it past you. Kevin: we're not happy with the current name of the methods and attribute, we were hoping you'd help us come up with a more appropriate name
I'm taking owner-ship because I wrote the ToolTip things. Some comments: a) There's already an option which prohibts recreating the ToolTip while moving the mouse inside a control (passing ToolTip#NO_RECREATE) this solves not 100% of your problems though I guess b) Instead of adding a method I'd favour a new constant which is passed to the constructor like ToolTip#NO_RECREATE
Tom, which ever you think is best if fine by me. We'd like to be able to get this into M4 though (it's our New & Noteworthy entry for this milestone), is there a chance we can get this in today/tomorrow?
I will post a revised patch shortly...
(In reply to comment #3) > Kevin: we're not happy with the current name of the methods and attribute, we > were hoping you'd help us come up with a more appropriate name Agree that "allowCursorToEnter" isn't right. It's not that you're allowing it, it's that you're promising to stick around if it looks like the user is trying to do that. Since it's work in conjunction with "shouldHideToolTip", then maybe "dontHideToolTipIfEntering"?
Thanks Tom, it turns out that ToolTip#NO_RECREATE does the job perfectly - no need for my patch. (You can confirm this by testing it with the snippet I included, if you're so inclined).
Ok, so ToolTip#NO_RECREATE does not work "perfectly" - Eric found a behaviour that conflicts with what we need. When the NO_RECREATE flag is set, the tooltip stays up even when we move the mouse - which is what we need. But, if the cursor goes to hover over another tree item, the old tooltip stays up, instead of closing and allowing us to open a new tooltip. What we need is simply the ability to allow the cursor to enter the tooltip. The way I implemented it in my attached patch is: we choose not to close the tooltip while the cursor is inside the rectangle formed by the cursor's original position and the opposite corner of the tooltip. Once the cursor is inside the tooltip, however, when it exits, the tooltip closes. I think that between the extensive javadoc comment I put in the patch, and the patch code itself, our solution is pretty clear. Tom, based on my patch, how do you think we should implement this behaviour (since you know the code better than we do)?
Moving to M6 - I'm completely swapped with company work. Is there still action needed?
No rush Tom, the way we're doing it now (making it 1 pixel inside the cell works OK for this particular case. It's still a valid enhancement I think but we're not blocked in any way on it...feel free to change the severity to 'enhancement', I won't argue...;-).
multi change because of intenion of stepping back as platform-ui committer
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
