Community
Participate
Working Groups
In the "open resource" dialog when you press down arrow on the keyboard, the focus jumps down to the list of the results. It doesn't works in the oppoiste direction. It would be great if the cursor is standing on the first list element(upper one) the focus would go back to the input field on pressing up arrow on the keyboard.
I would like to work on this in context of the #greatfix initiative, so anyone, please add the greatfix keyword and assign me. While investigating this, I have found that * the code to do this already exists since at least 2006 [1](actually from earlier, but the file got renamed/refactored/moved several time and there's no real value of tracking it further) - it handles SWT.ARROW_UP in the table in case the selection has only one item and that's the first one, it jumps back to the filter widget. * the fix for bug 178375 [2] contains a typo, while trying to make sure "if not using multiselect with ctrl+shift+arrow" it actually checks "if using UP AND Ctrl AND Shift", which got found only after the thing got released and verified, and the mistake is pointer out by the committer [3] The fix is a fairly trivial one, changing only two not equal signs (the one checking the Ctrl and Shift flags) to equals. [1] http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/bundles/org.eclipse.ui.workbench/Eclipse%20UI/org/eclipse/ui/dialogs/FilteredItemsSelectionDialog.java?h=R3_8_maintenance&id=570778ee8c5319618f94d7bf75706a01ccb6bb20 [2] http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/bundles/org.eclipse.ui.workbench/Eclipse%20UI/org/eclipse/ui/dialogs/FilteredItemsSelectionDialog.java?h=R3_8_maintenance&id=c5a3e8729b09f11f55264089d2258d455b7d88d3 [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=178375#c12
New Gerrit change created: https://git.eclipse.org/r/46218
Very very nice find, Robert! I've meant to dig into this myself. I wonder if this shouldn't be testing (e.stateMask & SWT.MODIFIER_MASK) == 0 instead. Otherwise UP and DOWN will still work with ALT or COMMAND (on OS X).
(In reply to Brian de Alwis from comment #3) > Very very nice find, Robert! I've meant to dig into this myself. > > I wonder if this shouldn't be testing > > (e.stateMask & SWT.MODIFIER_MASK) == 0 > > instead. Otherwise UP and DOWN will still work with ALT or COMMAND (on OS > X). You're right, it probably doesn't make any sense to assume that somebody would like to use ALT+UP or COMMAND+UP to jump back to the filter box, while he's using DOWN to jump down to the table. I'm updating the patch-set with this change.
I've discovered that it's a bit more involved: there's logic there to prevent selecting the ItemsListSeparator, but it doesn't prevent in a multiselect case. The code also presumes that multiselection is a combination of CTRL + SHIFT, which is not be true of all platforms. It seems to me that the right logic here is: if(key == ARROW_UP) { if((stateMask & MODIFIER_MASK) == 0 && selectedIndex <= 0 && selectionCount <= 1) { pattern.setFocus(); } else if(table.elementAt(selectedIndex) instanceof ItemsListSeparator) { table.deselect(selectedIndex); table.select(selectedIndex - 1); // select the object above } } else if(key == ARROW_DOWN) { if(table.elementAt(selectedIndex) instanceof ItemsListSeparator) { table.deselect(selectedIndex); table.select(selectedIndex + 1); // select the object below } }
I can't actually get the ARROW_DOWN case to work properly. It seems strange to have logic that can only avoid selecting the ItemListSeparator under certain circumstances. And since the dialog properly handles when the ItemListSeparator is selected, I'm inclined to replace the ARROW_UP with the following and remove the ARROW_DOWN case entirely: if (e.keyCode == SWT.ARROW_UP && (e.stateMask & SWT.MODIFIER_MASK) == 0 && list.getTable().getSelectionIndex() <= 0 && list.getTable().getSelectionCount() <= 1) { // If we're at the top then shift focus back to the pattern. // Set the selection to the first element in case the user // unselected all elements, otherwise the selection may wrap // to the last object which is disconcerting list.getTable().setSelection(0); pattern.setFocus(); } This seems to behave predictably on OS X.
(In reply to Brian de Alwis from comment #6) > I can't actually get the ARROW_DOWN case to work properly. It seems strange > to have logic that can only avoid selecting the ItemListSeparator under > certain circumstances. > > And since the dialog properly handles when the ItemListSeparator is > selected, I'm inclined to replace the ARROW_UP with the following and remove > the ARROW_DOWN case entirely: > > if (e.keyCode == SWT.ARROW_UP && (e.stateMask & SWT.MODIFIER_MASK) == 0 > && list.getTable().getSelectionIndex() <= 0 && > list.getTable().getSelectionCount() <= 1) { > // If we're at the top then shift focus back to the pattern. > // Set the selection to the first element in case the user > // unselected all elements, otherwise the selection may wrap > // to the last object which is disconcerting > list.getTable().setSelection(0); > pattern.setFocus(); > } > > This seems to behave predictably on OS X. I like this better than the previous one, as that's not too easy to implement, I've spent some hours to do that. This solution behaves predictably on Linux+GTK too, maybe someone confirming this on Windows would be nice, but as Windows uses the same modifiers as Linux, I guess we should be fine. I will update the gerrit request with this proposal. Thanks for looking into this.
I'd like to defer this to 4.6.
Updating target based on comment 8.
I looked at this a bit closer. We should not fix this as this would result in an inconsistent UI. The same pattern is applied all over the IDE i.e. moving down from a search field goes into the list and moving up stops at the first element. You e.g. see this in several preference pages or views. Sorry Robert.
(In reply to Dani Megert from comment #10) > I looked at this a bit closer. We should not fix this as this would result > in an inconsistent UI. The same pattern is applied all over the IDE i.e. > moving down from a search field goes into the list and moving up stops at > the first element. > > You e.g. see this in several preference pages or views. > > Sorry Robert. Don't worry, this is your call after all. However, I completely agree with the reporter that even if this is consistently like this everywhere in eclipse, it doesn't make much sense to have the down arrow change component, but up arrow not doing the opposite. Too bad that this won't get fixed, this is a really great a11y feature, pressing up arrow is sooo much easier then pressing Shift+Tab. I guess after this decision you can remove the relevant code, as it's clear that the modifier handling is broken there.
