Community
Participate
Working Groups
Popup tooltip in the task list been bothering me for some time. Recent UI improvements for the Task list view made this tooltip feel even worse.
Created attachment 68874 [details] current and suggested tooltip I mostly using tooltip to read the ending of the task summary, and it is quite uncomfortable for this purpose. See top image on this attached screenshot. The main problem is that text which you want to read jumps aside, so you have to start to scan it from the beginning. But then shown text label is not the same that you could see in the task list, because task id is not being shown on the tooltip. If you look at the native tooltips, they are shown right in place, so it allow to continue reading labels without interruption. I've tried to put a possible UI mockup that sould improve tooltip usability (bottom image on the attached screenshot). Though I am not sure if tooltip should overlay selected row or it should be shown on the row below selected one.
I agree with the proposal. However, if we do this we will still need the special case that that the tooltip does not move off the edge of the screen if there is not enough room, since the default Task List location is the right side of the workbench.
(In reply to comment #2) > if we do this we will still need the special case that that the tooltip > does not move off the edge of the screen if there is not enough room, > since the default Task List location is the right side of the workbench. In that case we can probably use the same tootip position, but wrap the summary text.
I have patch for this but it require patch from bug 194070 applied first.
Eugene: what's the status of this? Is it worth exploring the current patch or should we consider first moving to the new JFace ToolTip support?
(In reply to comment #5) > Eugene: what's the status of this? Is it worth exploring the current patch or > should we consider first moving to the new JFace ToolTip support? I haven't actually submitted any patches to this issue, after I've been blamed about breaking something on OS X. I may still have some code around, that implementing aligning tooltips to the cell content in the tree view. Like before, it does not change any events, but changes calculation of tooltip position. I took a quick look at the jface tooltips and it seems like they all bound to the mouse pointer - hence not going to help for this. See http://wiki.eclipse.org/index.php/JFaceSnippets
Should this one also be in Steffen jurisdiction? Any objections or thought on the proposed mockup (position and the layout changes)?
I'll address this within the next few weeks. Now that the tool tip can be made visible through the keyboard (F4) and stays visible when another task is selected the positioning needs to be improved anyways. Unfortunately platform is moving slow on bug 205872 which affects people using the task list on a second monitor. We might have to duplicate JToolTip to improve the positioning of the tool tip.
> Unfortunately platform is moving slow on bug 205872 which affects people using > the task list on a second monitor. We might have to duplicate JToolTip to > improve the positioning of the tool tip. > I can't commit until I get a positive feedback from one someone with a multi-monitor setup, sorry. It would be sad if mylyn duplicates code because of this.
> I took a quick look at the jface tooltips and it seems like they all bound to > the mouse pointer - hence not going to help for this. See > http://wiki.eclipse.org/index.php/JFaceSnippets > You can fixup the location. The default is to show them at the cursor position.
Thanks Tom. I would very much like to avoid copying code. (In reply to comment #10) > > I took a quick look at the jface tooltips and it seems like they all bound to > > the mouse pointer - hence not going to help for this. See > > http://wiki.eclipse.org/index.php/JFaceSnippets > > You can fixup the location. The default is to show them at the cursor position. Great! As far as I can tell from the API we should be able to able to implement custom positioning by overriding getLocation().
(In reply to comment #11) > Great! As far as I can tell from the API we should be able to able to implement > custom positioning by overriding getLocation(). Steffen, please note that tooltip location is only half of the story. The text shown on the tooltip should be also aligned and match the selected task list entry (as on attached mockup screenshot). I actually had this implemented even without jface tooltips, but didn't want to submit patch for that because everybody seem sensitive about any changes in that code.
> > You can fixup the location. The default is to show them at the cursor position. > > Great! As far as I can tell from the API we should be able to able to implement > custom positioning by overriding getLocation(). > Yup.
(In reply to comment #12) > Steffen, please note that tooltip location is only half of the story. The text > shown on the tooltip should be also aligned and match the selected task list > entry (as on attached mockup screenshot). > > I actually had this implemented even without jface tooltips, but didn't want to > submit patch for that because everybody seem sensitive about any changes in that > code. Please attach the code if you still have that implementation so I can investigate how we can make that work with the JFace ToolTip based implementation.
(In reply to comment #14) > Please attach the code if you still have that implementation so I can > investigate how we can make that work with the JFace ToolTip based > implementation. Unfortunately I had to drop these changes together with other rejected stuff.
Created attachment 82298 [details] patch
Created attachment 82299 [details] mylyn/context/zip
The tooltip is now positioned below the selected item in the task list and should be repositioned correctly when the task list is scrolled by keyboard. I have only tested on Linux. Please test on other platforms.
Created attachment 82302 [details] screenshot of current positioning
Guys, can you please reconsider to use the same label between tooltip and the task list entry. The major point is that you don't have to eye-jump to the tooltip text that is currently shifted because of the task key (see the difference on my screenshot).
(In reply to comment #18) > The tooltip is now positioned below the selected item in the task list and > should be repositioned correctly when the task list is scrolled by keyboard. I > have only tested on Linux. Please test on other platforms. Works for me on OS X.
(In reply to comment #20) > Guys, can you please reconsider to use the same label between tooltip and the > task list entry. The major point is that you don't have to eye-jump to the > tooltip text that is currently shifted because of the task key (see the > difference on my screenshot). +1 for the entry being the same (i.e. the same label as the Task List shows).
Done.
Steffen, it looks really great, and I really like how tooltip stick when you do the browse and mark as read with the keyboard (F8) it is enormous and long awaited usability improvement and even more then one would expect from those shortcuts, because of the way tooltip is behaving. Though there is a little glitch in positioning. When task list have scroll bar and tooltip is shown on task entry that have incoming changes, after you click F8 (mark as read and go to next) tooltip is shown not next to the entry selected after this operation, but one entry below. It seems somehow related to the scrolling.
(In reply to comment #24) > Though there is a little glitch in positioning. When task list have scroll bar > and tooltip is shown on task entry that have incoming changes, after you click > F8 (mark as read and go to next) tooltip is shown not next to the entry selected > after this operation, but one entry below. It seems somehow related to the > scrolling. Yes, I have noticed that as well. It can also happen that the tooltip disappears when the tree scrolls "too much". It might be possible to fix the problem by listening to scroll events.
Created attachment 83106 [details] positioning on windows Steffen, the new label look really great, though now it is actually possible to see that tooltip is off 3px on windows. Also, it have duplicated label with the bug number on second line, perhaps need to be addressed on bug 205861 (so as the task icon should be shown on first row and repo icon on the second, next to the repository)
I have added a hook to reposition the tooltip after the tree is refreshed and moved the tooltip by three pixels to the right on Windows. Leo, how about the alignment on Mac OS?
Did you guys now use the JFace-Tooltips or copied over the code if it is the latter it might be interesting what changes could be ported back to JFace-ToolTips.
Created attachment 83206 [details] Mac alignment patch Patching so that Carbon has the same alignment as GTK.
(In reply to comment #28) > Did you guys now use the JFace-Tooltips or copied over the code if it is the > latter it might be interesting what changes could be ported back to > JFace-ToolTips. Tom, this tooltip is heavily bound to Task List view. I've opened bug 210186 to allow to reuse it in other places, but it is still fairly specific to Mylyn UI. Steffen added focus listener to the tooltip component that hides tooltip when focus is lost. Perhaps you could do that in the tooltip itself, though it is unclear at that point that listener should be unregistered and it is also strange that tooltip class does not provide regular dispose() method.
Thanks Leo, patch applied. Tom, I'll review the current Mylyn tooltip code and make suggestions for backporting. We would like to make the tooltips feel more native (e.g. by using the same gradient for the background) but I haven't looked into that, yet.
Tom: do you know if it's possible to get native (e.g. gray gradient on Vista) tooltips that have composites in them? The square yellow box look is looking dated on Vista.
I'm sorry I don't have an idea how to get them but SWT is providing transparency in 3.4 maybe this is a solution? Besides that I have no Vista how does a ToolTip look like there?
interesting bugs might be #188333 and bug #178044
