Bugzilla – Full Text Bug Listing
| Summary: | Improve tooltip positioning when tasklist is on bottom of screen | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Willian Mitsuda <wmitsuda> |
| Component: | Mylyn | Assignee: | Project Inbox <mylyn-triaged> |
| Status: | CLOSED MOVED | QA Contact: | |
| Severity: | minor | ||
| Priority: | P4 | CC: | overholt, steffen.pingel |
| Version: | dev | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 205861 | ||
|
Description
Willian Mitsuda
Thanks for your input on this Willian. It took quite a bit of discussion to get the tooltip positioning the way it is now: bug 189313. It is optimized around the use case of quickly browsing incoming changes. It should always show in the same position relative to the selected item so that the text in the tooltip aligns with the text in the task list. This has the advantage of getting the same behavior whether the tooltip is triggered by mouse or by keyboard. I have used it for the past few weeks and it works very well for me. I mostly use keyboard navigation (F6/F7/F8) to scan through my incoming changes and avoid opening the task editor for most changes. I agree that it is not desirable to have the tooltip under the cursor but that is how the JFace ToolTip class currently aligns the tooltip to avoid crossing of screen boundaries. Would it work for you to align the tooltip above the selected task list item in that case? As Steffen already explained the tooltip is aligned to the task entry and not to the cursor. This way it is better work with the eye flow, so you can eye-match shortened text with full text on the tooltip. Also try new navigation without mouse (I think it is very cool) - hit F4 to show tooltip and then use up/down keys, or F8 (to mark as read and jump to next unread task). Disclaimer: I have Task List view on the same tab group as Package Explorer (logically these views usually not need to be seen at the same time) Anyways, I do agree that tooltip positioning when there is not enough space on the screen need some work. It could be positioned above selected entry if there is not enough space below. (In reply to comment #1) > Thanks for your input on this Willian. It took quite a bit of discussion to get > the tooltip positioning the way it is now: bug 189313. It is optimized around > the use case of quickly browsing incoming changes. It should always show in the > same position relative to the selected item so that the text in the tooltip > aligns with the text in the task list. This has the advantage of getting the > same behavior whether the tooltip is triggered by mouse or by keyboard. Although it seems optimized for keyboard navigation, I think it is "disoptimized" when it is activated by mouse. What about apply the current behavior only when activated by keyboard, and left the normal, predictable, behavior when activated by hovering the mouse? The big problem I see is that the current behavior allows it to appear under the mouse cursor in some occasions: 1 - When the tooltip is big and you don't have enough space on bottom of screen. 2 - When you position the mouse cursor near the bottom of the tree item. In both cases you are not able to see part of tooltip which is covered by mouse cursor. On these cases, the instinctive reaction is to move the mouse a little to try to uncover the tooltip, but disappears. In case (1), it is particularly annoying because sometimes I this to double-click a task to open it, but the tooltip appears and consumes one click event. Note that in java editor, they put some blank space between the editor line where you are pointing to, and the tooltip for class/method names, avoiding having the tooltip covered even when it is activated by pointing the bottom of the word. > I agree that it is not desirable to have the tooltip under the cursor but that > is how the JFace ToolTip class currently aligns the tooltip to avoid crossing of > screen boundaries. Would it work for you to align the tooltip above the selected > task list item in that case? Well, I think the golden rule is to never cover something you want others to see :) (In reply to comment #2) > As Steffen already explained the tooltip is aligned to the task entry and not to > the cursor. This way it is better work with the eye flow, so you can eye-match > shortened text with full text on the tooltip. Yes, as I explained above, I don't think it is a bad idea (for keyboard activation). But for mouse activation, I think it is problematic when you have to explain to someone why something works the way it is. > Also try new navigation without > mouse (I think it is very cool) - hit F4 to show tooltip and then use up/down > keys, or F8 (to mark as read and jump to next unread task). Yes, it looks very cool :) I'll give a try. (In reply to comment #3) > > As Steffen already explained the tooltip is aligned to the task entry and not to > > the cursor. This way it is better work with the eye flow, so you can eye-match > > shortened text with full text on the tooltip. > > Yes, as I explained above, I don't think it is a bad idea (for keyboard > activation). But for mouse activation, I think it is problematic when you have > to explain to someone why something works the way it is. I still find it more convenient to have tooltip aligned to the entry and with mouse events it is even easier to read. Note that it is in fact aligned even in the java editor. But like I said, we do need to improve positioning when tooltip don't fit on the screen (especially at the bottom) and it shouldn't be hard to fix. Mouse cursor never really bugged me... Would it be better if it works the same way as native tooltips, when entry is actually covered by the tooltip? See for example long entries in the package explorer. Also, swallowing clicks is sounds like a bug in platform tooltip code, I don't remember if there is a handler on our side. (In reply to comment #4) > Note that it is in fact aligned even in > the java editor. I think in java editor the alignment does looks good because usually the token you are hovering are usually short, with few characters, so the left border never goes so far from the mouse pointer. But this is a minor issue. > Mouse cursor never really bugged me... Would it be better if it works the same > way as native tooltips, when entry is actually covered by the tooltip? See for > example long entries in the package explorer. I don't think so. The tooltip in tree control has the advantage of not consuming a click, so you don't need to triple-click to expand the node as if there isn't a tooltip, and it does not disappear if you move the cursor around to read what is covered by the cursor. And it does not prevents you of seeing other tree items. OTOH, implementing something similar in task list's tooltip would not look good because it uses multiline tooltips. So you would have to move the mouse outside the tooltip to see the next tree item. In java editor, they have something similar for the folded sections. If you hover the "-" sign in vertical ruler, the tooltip containing the folded area covers the first folded region's line. But in that case it works nice because the tooltip and the region where you have to hover never overlap. Willian, don't you think you are fading away from positioning to general tooltip behavior? I believe we all agreed that positioning need to be improved. The current position is calculated manually and I don't think native/default behavior is actually any better then what we have in your use case. But things like swallowed clicks better be tracked in a separate bug report (personally, I never seen it). (In reply to comment #6) > Willian, don't you think you are fading away from positioning to general > tooltip behavior? Well, since the current positioning was settled around the use case of incoming navigation, I think there is no way to avoid such discussion. (In reply to comment #3) > Although it seems optimized for keyboard navigation, I think it is > "disoptimized" when it is activated by mouse. What about apply the current > behavior only when activated by keyboard, and left the normal, predictable, > behavior when activated by hovering the mouse? Unfortunately this would not fix the main issue raised in this report namely having the tooltip appear under the mouse cursor. > Note that in java editor, they put some blank space between the editor line > where you are pointing to, and the tooltip for class/method names, avoiding > having the tooltip covered even when it is activated by pointing the bottom of > the word. The task list also offsets the tooltip by one pixel but we could increase that amount. Could you modify TaskListToolTip.Y_SHIFT and let me know which value works best for you? > > I agree that it is not desirable to have the tooltip under the cursor but that > > is how the JFace ToolTip class currently aligns the tooltip to avoid crossing > of > > screen boundaries. Would it work for you to align the tooltip above the > selected > > task list item in that case? > > Well, I think the golden rule is to never cover something you want others to see > :) I am not sure what you mean by that? Basically I would like to make the behavior consistent with the Java editor which never shows the tooltip under the cursor. (In reply to comment #5) > I don't think so. The tooltip in tree control has the advantage of not consuming > a click, so you don't need to triple-click to expand the node as if there isn't > a tooltip, and it does not disappear if you move the cursor around to read what > is covered by the cursor. And it does not prevents you of seeing other tree > items. That's an interesting point. I find that convenient since the tooltip quickly goes away when I move the mouse. Could you explain in more detail which information is covered by the cursor that is not available from the tooltip? All information that is displayed in the tasklist should be available from the tooltip as well. I haven't kept up with this discussion, but one of Willian's points resonated with me: our solution should be optimized for mouse use over keyboard use. (In reply to comment #9) > I haven't kept up with this discussion, but one of Willian's points resonated > with me: our solution should be optimized for mouse use over keyboard use. Not sure if you haven't mistyped anything here. Anyways, I don't agree that current tooltip positioning is optimized for mouse or keyboard use, but it is optimized for readability of the task summary, regardless how tooltip been activated. I won't be able to get to this for 3.0. Marking as helpwanted to indicate that we could take a contribution that improves positioning when tooltips are displayed on the bottom of the screen. Andrew, interested in creating a patch for this bug :)? Thanks for pointing this out to me, Steffen. I'll see if I can find some time. Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn |