Community
Participate
Working Groups
many times I want to get a set of files from a package into the context. currently the process is pretty annoying, for each file I need to: * alt-click the parent package. * click on the file. since the alt-mode turns off when I click the file, I need to do the whole thing again. it gets extra annoying if I am in hierarcial package presentation, and I need to 'drill down' the packages list for each file. maybe a solution can be a new 'sticky' alt click mode, that remains until I explictily turn it off? (ALT-CTRL maybe?)
At some point ctrl-click on windows used to work for this.
Have you tried holding down Alt while you click and browse? That will make the expanded state stick until you make a selection without holding down Alt.
sure, I do that all the time. it resets the state as soon as I select some kind of element like a file. I am not certain, but I thing its also behaving differently on Windows and Linux: on Linux, as soon as I touch the file its selected and the expended state is reset. on Windows, if I hold the mouse down for a second, some times the selection remain open. I can't verify the windows behavior because I am on Linux at the moment.
well, verified on both windows and linux: when I select an item, the view-all mode turns off.
If I understand you correctly that is the intended behavior, but note that it stays sticky until there is a selection: http://wiki.eclipse.org/index.php/Mylar_User_Guide#Alt.2BClick_navigation We have stayed away from "sticky" modes because the state of the tree can get confusing, the discussion about that is on bug 112233. Also, note that we can't use any Ctrl combinations and have other challenges with modifier keys on Linux (bug 116948 and Linux instructions in User Guide). But if you have a proposal for how to improve the current interaction please do post it here so that we can explore further.
here is a proposal: use the alt press-state as a sticky mode controller. currently there are two type of alt-selects: 1. selection of a parent, which expands it and expose all its children. 2. selection of a child, which elevate its interest and switch the selection expose-flag off my suggestion is that on the second case - if the alt-key is still down, don't reset the expose-flag. now while the user hold the alt the sticky mode is on: when he is drilling through parent packages its already what happens. to exit the condition he need to select an item without holding down alt, or possibly just click on some empty space inside the tree (without alt). another important thing is that there should be visual feedback for this state. one possibility for that is to draw a bold border around the component while its in sticky mode. another thing, which will improve usability - although may not be worth a UI clutter - is to give the user some way to exit sticky mode without the click-some-where-without-holding-alt voodoo. some button that will only appear while in sticky mode maybe.
(In reply to comment #6) > here is a proposal: > use the alt press-state as a sticky mode controller. We've been there about half a year ago. The problem with such approach that pressed key would interfere with ability to select multiple unfiltered entries and call popup menu on them.
Omry: while a lot of this brings up the trickiness discussed on bug 112233, I think that both the child/parent differentiation and the visual feedback aspects of your proposal are worth exploring and could make the UI more intuitive. Tentatively scheduling for 2.0
The only change we still hope to make for 3.0 related to this is bug 178583.
Another idea in terms of visual affordance for the Alt+Click behaviour is to custom drawn a small expansion button to the right of the element. Upon clicking this button would expose ALL elements (not just the important ones). This button would only be drawn upon mouse hover and only be presented if there were actually uninteresting elements to reveal.
As discussed in person with Rob, I really like this idea and will try to prototype something in the 2.1 timeframe. Another constraint is that the button should only be drawn if there is a non-interesting element below that can be shown if the affordance is clicked.
Can we please make this optional or maybe give it a spin from the sandbox before dropping it into the public? It seems like custom drawn stuff is hard to make to work correctly on all platforms. Also, dynamic popups can be quite annoying (if they are big) or hard to aim to (if they are small) and they may also interfere with tooltips and popup menus. All in all, it could get quite messy and may not worth the time, given the other almost 800 open bug reports.
For 2.1 I have added a new action called Show Filtered Children (Alt+click) that will be added to the popup menu of the Package Explorer if a task context is active. If this works well for Java elements in 2.1 we can extend to the other views that support focus. Details will be in the New & Noteworthy.
For 2.2 we have the following improvement, which prevents the view from getting 'stuck' in a partially unfiltered state: Alt+click unfiltering returns on first non Alt+click mouse click in the view.
*** Bug 208404 has been marked as a duplicate of this bug. ***
Fixed context menu behavior (i.e. tree filtering over eagerly when a context menu on a folder is clicked).
Created attachment 95148 [details] progress from EclipseCon
Need to defer: http://wiki.eclipse.org/index.php/Mylyn/3.0_Plan#Deferred_Items
Shawn: Congratulations on your new commit rights :) We can work on this one together but I'd like you to drive it if it can stay on your queue. The patch I did is a start.
We have run out of time to get this into 3.2, postponing to 3.3.
*** Bug 213532 has been marked as a duplicate of this bug. ***
In the light of the lacking Meta-Key support of Eclipse, I wonder why this issue is postponed again. Please remember: Alt-Key is used by default in KDE.
Created attachment 188864 [details] updated patch Here is an updated patch that gets us pretty close to having this done. We still need a good icon and I would like to find a way to do the update without triggering a tree redraw since that seems really expensive.
Created attachment 188865 [details] mylyn/context/zip
Steffen, could you try this patch on Linux and let me know how it works?
Wow, that's awesome! Works nicely on Gtk. I only noticed a few nits: * The affordance stayed when I unfocused or deactivated. Would be good to hide it in those cases. * When I clicked a node that did not have children there was no feedback that the tree could not be unfiltered further. Could we make the icon turn into a red X or something like that? * Can we show some sort of feedback when hovering over the icon to indicate that it is clickable? For the icon a "+" might work as it usually indicates expand.
Created attachment 188935 [details] updated patch Here is a patch that addresses some of these issues. I still think that we need a different icon, but we are pretty close to being able to commit this so that we can get feedback. Should we add a preference to disable this?
Created attachment 188936 [details] mylyn/context/zip
Created attachment 188948 [details] patch Here is another patch. I think that all that we have left to do here is consider adding the ability to turn this off and to get better icons potentially.
Created attachment 188949 [details] mylyn/context/zip
Committed.
Created attachment 188965 [details] mylyn/context/zip
Created attachment 188966 [details] tooltip showing in Task Editor on Gtk
Great stuff! This works well on Gtk now. Reopening to discuss minor nits from a bit of testing: * The tooltip does not disappear when I move the mouse outside of the "+" icon and it shows for other controls outside of the package explorer (see screenshot). * I find the graying of the "+" is too subtle. On my display it's very hard to see the difference. Can we try showing a gray "x" intstead? * The tooltip seems to have an extra line break at the end making it bigger than necessary. Not sure if that's intentional.
One more thing, I would try centering the icon vertically. It looks like it's aligned with the top edge of the cell.
We need to take a look at the Markers view which shows the "+" icon in each column. It should probably be limited to the first column.
Great news, its been 4 years minus two weeks since I reported this! :) looking forward to see this in action.
Steffen, I think that I have fixed these issues. Can you give it a shot on Linux and let me know?
I still seem to get the tooltip when I move the mouse over other parts of the IDE, e.g. the Java editor.
It turns out that there is a problem with SWT Tooltips on Linux where it isn't properly disposed which is causing this problem. We now use the SWT.BALLOON style for gtk only which fixes this problem. Steffen, can we cll this done?
Thanks for fixing this! I have filed bug 337269 to make the SWT team aware of the Gtk tooltip weirdness. I have kicked off a weekly build at https://hudson.eclipse.org/hudson/job/mylyn-release/32/console . Once that completes the build will be available from http://download.eclipse.org/mylyn/snapshots/weekly . Omry, great to hear that you haven't given up on Mylyn! We are looking forward to your feedback.
One more nit :), if I click on an item in the tree that does not have children the affordance turns into an "X" even when I don't click in the icon area.
Steffen, I have fixed that and have improved redraw performance. It would be great if you could make sure that it works as expected as well.
Created attachment 189205 [details] mylyn/context/zip
Created attachment 189232 [details] delay drawing when mouse is moving fast I'm not having performance problems anymore, but the + moving around could still be annoying. Here's a patch to delay drawing. The catch is that it doesn't always draw it over the tooltip that appears in Windows when an item doesn't fit horizontally (which is odd looking anyway).
It should be hidden on window activation.
Thanks Sam! I have applied this patch with a couple minor changes so that the + isn't left behind when leaving the view.
Created attachment 189452 [details] screenshot when item spans visible area When an item is as wide as the visible area of the tree the on hover affordance is only partially visible. I would expect it to be drawn further left in that case.
Comitted a fix.
Great stuff Shawn!
Great work, Shawn! I think we are done here for 3.5.
