Community
Participate
Working Groups
Running latest dev build with Eclipse 3.4, alt-click unfiltering is practically doesn't work. Unfiltered elements filtered back once I click on anything and it is impossible to open editor or even popup menu on those. It does not affect absolutely all elements, but when it happens it is very distracting and less passionate user would simply disable or remove Mylyn.
Eugene: these changes are not necessarily final, but were by design (see bug 175655 comment#14 and the duplicate in comment#15). But I was concerned that this would cause problems with other use cases, although I'm not sure how it could cause problems showing a context menu. Could you please describe the exact steps that break for you?
(In reply to comment #1) > Could you please describe the exact steps that break for you? Very simple. Activate some task, unfilter some element with Alt-click, doubleclick on it to open an editor, unfilter another element, try to open popup menu, then repeat. Very quick I can't open any editors or menus after alt-click, unfiltering just go off. This is the first time I wanted uninstall Mylyn because it is getting in a way of thought more then it is helping. It is even beyond distracting.
(In reply to comment #2) > Very simple. Activate some task, unfilter some element with Alt-click, > doubleclick on it to open an editor, unfilter another element, try to open popup > menu, then repeat. Very quick I can't open any editors or menus after alt-click, > unfiltering just go off. I have made a bunch of related Alt+click fixes. Could you please try again? I could not get any failures, but the one thing I was confused about was "unfilter some element with Alt-click, doubleclick on it to open an editor", since I think the normal click stream for this is the following? 1) Alt+click package 2) Left click file to make it interesting 3) Double click file to open Did we previously support skipping (2)? If so it was unintentional, but should be considered.
Sounds like there is some miscommunication. I didn't realize that (2) is needed. It essentially turning plain double click into a triple click with a mouse move in a middle. I don't think it used to be like that. Also, it is really confusing when selected element jumps out somewhere when you right-click on it (without left clicking first). So, all in all I do think that skipping (2) is important and it should be the regular behavior.
Eugene, I'm aware of the following two problems that you have mentioned during a previous call: 1) Disjoint selections don't work: I have added this support and updated the doc: http://wiki.eclipse.org/Mylyn_User_Guide#Alt.2BClick_navigation 2) Double-click is not supported: this was never intentionally supported but likely worked due to performance problems. We can try to add support fo it. I have turned this bug into (2).
Noticed the following code been committed: if ((event.stateMask & SWT.CTRL) != 0) { maybe it should be actually using SWT.MOD1 as a platform neutral equivalent for Ctrl modifier.
The documentation says Ctrl. Leo, Steffen: do you know if Mod1 mapst to Ctrl on both Linux and Mac?
I am not sure about Linux but from the org.eclipse.ui.commands documentation it sounds like "Mod1" maps to "Command": The modifier keys can also be expressed in a platform-independent way. On MacOS X, for example, "Command" is almost always used in place of "Ctrl". So, we provide "M1" which will map to either "Ctrl" or "Command", as appropriate. Similarly, "M2" is "Shift"; "M3" is "Alt"; and "M4" is "Ctrl" (MacOS X). If more platforms are added, then you can count on these aliases being mapped to good platform defaults.
(In reply to comment #8) > I am not sure about Linux but from the org.eclipse.ui.commands documentation it > sounds like "Mod1" maps to "Command": Yeah, M1 is Command on the Mac.
Thanks guys, changed to SWT.MOD1 and updated documentation.
Looks like we have a regression with Ctrl+click when focused.
(In reply to comment #11) > Looks like we have a regression with Ctrl+click when focused. With the current infrastructure it will be tricky to support both the request for Ctrl+click to make multiple things interesting and to set the disjoint selection. I have updated the User Guide with the current policy: http://wiki.eclipse.org/Mylyn_User_Guide#Alt.2BClick_navigation If this is desired we would need to maintain the our own list of disjoint selection over the viewer, which is too big a change for 2.2. Let's see how the current policy works and consider this along with bug 175655. Alt+double click is now supported. Needs additional testing to make sure that we don't have a timing problem, since we now just queue the next event. There's a good chance that should work all the time since the viewer already has it's open event queued, but we should watch for failures.
Created attachment 85322 [details] mylyn/context/zip
I just played with current changes from the HEAD. It is still quite confusing. Sequence Alt-click, Alt-Ctrl-click, Alt-Ctrl-click doesn't work (it filtering out expanded node on first Alt-Ctrl-click) Sequence Alt-click, release-Alt, Ctrl-click, Ctrl-click is still only select the last element. Sequence Alt-click, release-Alt, Alt-Ctrl-click, Alt-Ctrl-click does work (but it is very confusing to use Alt-Ctrl-click instead of simple Ctrl-click) I am not sure if this is intentional, but it is completely unclear from the text in the user guide.
After additional experimentation I believe that we cannot go out in 2.2 without proper support for Ctrl+click making disjoint selections because it's too big a change with how viewers typically work. Eugene: when doing this I will also review the sequences that you listed.
Mik, sorry, I've got lost in the language. Can you please clarify if working Ctrl-click selection is going into 2.2 or not?
I am still having issues with regular Alt-click, then double-click sequence, even for Java files. It does work when task is just started, but then it suddenly stops at some point. My only theory is that it stop working after this element been decayed so after that you can't make it interesting again. I have to use popup menu to open editor instead of doubleclick on the java file. After editor is opened resource is still not being unfiltered, so I have to close editor (editor context management is on) and after that Alt-click, Alt-doubleclick work. This all also mean that there are most probably another issue with interesting things being decayed too fast.
Yay! I think that I finally figured out all of the problems happening around missed Alt+clicks and Alt+double-clicks. There was a UI concurrency problems between interaction event triggered selections, our refresh policy, and timing. We now wait OS.GetDoubleClickTime() before triggering any additional refresh. This boils down to the fact that both Alt+double-click and Ctrl+click after Alt+click are both supported. More importantly, there should not be any missed Alt+clicks anymore. Let's watch carefully for that. A new weekly biuld will be available tomorrow. (In reply to comment #17) > This all also mean that there are most probably another issue with interesting > things being decayed too fast. While I realize that it felt that way, it is very unlikely that this was the cause of the problem. Please report if you see anything like this again. (In reply to comment #14) > Sequence Alt-click, Alt-Ctrl-click, Alt-Ctrl-click doesn't work (it filtering > out expanded node on first Alt-Ctrl-click) Alt+Ctrl+Click is handled the same was as Alt+Click in order to avoid confusion. If there is a use case for Alt+Ctrl+Click to do something different please file a new bug.
Created attachment 85521 [details] mylyn/context/zip
(In reply to comment #18) > Yay! I think that I finally figured out all of the problems happening around That's a great news. > Alt+Ctrl+Click is handled the same was as Alt+Click in order to avoid confusion. > If there is a use case for Alt+Ctrl+Click to do something different please file > a new bug. That would be the sequence I tried to use to select multiple resources from the list unfiltered after first Alt-Click without thinking about it. Releasing Alt is an extra gesture that didn't feel natural.
Mik, unfortunately the current implementation does not compile on Linux. I have temporarily comment out the windows specific part. I am not sure if SWT has a platform independent way of determining the double click interval. We might have to use reflection to access these internals.
It looks like Display.getDoubleClickTime() is what we need. Please review the changes I made to BrowseFilteredListener.
*** Bug 213498 has been marked as a duplicate of this bug. ***
Steffen: changes look good, great that you found a better way to get that timing. Eugene: please consider commenting that you would like the Alt+Ctrl+click sequence to do something different on bug 175655 (note that this can't be done for 2.2 becuase there will be complications and because we will have to work out the right policy).
(In reply to comment #24) > Eugene: please consider commenting that you would like the Alt+Ctrl+click > sequence to do something different on bug 175655 (note that this can't be done > for 2.2 becuase there will be complications and because we will have to work out > the right policy). I never suggested it should do something different. If you use Ctrl-Alt-click when to context filter is active, it works for selecting multiple elements. So it would make sense to have the same when context filter is active, unless, of course, there are technical reasons that it can't be done. Anyways, I already commented about Ctrl-Alt-click on one or two bug reports, so please feel free to use those comments if you like, because I simply can't keep up with you jumping between so many bug reports. :-)
