Improve quick search behavior in OutlineView, TreeTable, and ListView#8319
Open
eirikbakke wants to merge 1 commit intoapache:masterfrom
Open
Improve quick search behavior in OutlineView, TreeTable, and ListView#8319eirikbakke wants to merge 1 commit intoapache:masterfrom
eirikbakke wants to merge 1 commit intoapache:masterfrom
Conversation
eirikbakke
added
Platform
eirikbakke
force-pushed
the
pr-quicksearch
branch
from
eea89d9 to
d41f4f7
Compare
Details: * For OutlineView and TreeTable, avoid changing the selection when pressing Escape. (TreeView already has the desired behavior.) * Add F3 and Ctrl/Command+G as alternative keystrokes for next-match (and Shift variants for previous-match). * Have QuickSearch select all when invoking Ctrl+F or alternative shortcuts while the search bar is already open. * Make the ListView's quick search box look more modern, and consistent with that of OutlineView/TreeView. Use the magnifying glass icon instead of the text 'Search', and use a flat border style. * Add more alternative find-next/previous keystrokes for ListView, like we did in QuickSearch (which is used by TreeView and OutlineView but not ListView). On Ctrl+F or F3, open the search bar, or select-all the existing text if it is already open. * In OutlineView and TreeTable, avoid backtracking to the first hit if backspace is pressed on a still-matching selection.
Contributor
matthiasblaesing
left a comment
matthiasblaesing
left a comment
There was a problem hiding this comment.
I think this introduces regressions in the IDE (see inline comments). I don't think this should merged as is.
| keyCode == KeyEvent.VK_LEFT || keyCode == KeyEvent.VK_RIGHT || | ||
| keyCode == KeyEvent.VK_TAB || keyCode == KeyEvent.VK_F3) { | ||
| keyCode == KeyEvent.VK_TAB || keyCode == KeyEvent.VK_F3 || | ||
| keyCode == KeyEvent.VK_ENTER && ke.getModifiersEx() == KeyEvent.SHIFT_DOWN_MASK || |
Contributor
There was a problem hiding this comment.
Suggested change
| keyCode == KeyEvent.VK_ENTER && ke.getModifiersEx() == KeyEvent.SHIFT_DOWN_MASK || | |
| (keyCode == KeyEvent.VK_ENTER && ke.getModifiersEx() == KeyEvent.SHIFT_DOWN_MASK) || |
Comment on lines
+795
to
+796
| keyCode == KeyEvent.VK_F3 && e.getModifiersEx() == KeyEvent.SHIFT_DOWN_MASK || | ||
| keyCode == KeyEvent.VK_ENTER && e.getModifiersEx() == KeyEvent.SHIFT_DOWN_MASK || |
Contributor
There was a problem hiding this comment.
Suggested change
| keyCode == KeyEvent.VK_F3 && e.getModifiersEx() == KeyEvent.SHIFT_DOWN_MASK || | |
| keyCode == KeyEvent.VK_ENTER && e.getModifiersEx() == KeyEvent.SHIFT_DOWN_MASK || | |
| (keyCode == KeyEvent.VK_F3 && e.getModifiersEx() == KeyEvent.SHIFT_DOWN_MASK) || | |
| (keyCode == KeyEvent.VK_ENTER && e.getModifiersEx() == KeyEvent.SHIFT_DOWN_MASK) || |
| } | ||
| }); | ||
| InputMap im = component.getInputMap(JComponent.WHEN_ANCESTOR_OF_FOCUSED_COMPONENT); | ||
| im.put(Utilities.stringToKey("D-F"), "openQuickSearch"); |
Contributor
There was a problem hiding this comment.
This is a problem in Project and Files views in the IDE as it overrides the project wide searches.
| keyCode == KeyEvent.VK_F3 && e.getModifiersEx() == 0 || | ||
| /* We can't use ENTER to go to the next match, as this keystroke is used to | ||
| invoke the row's default action. */ | ||
| /* keyCode == KeyEvent.VK_ENTER && e.getModifiersEx() == 0 || */ |
Contributor
There was a problem hiding this comment.
Does it really make sense to handle Shift-Enter, but not Enter?
| quickSearchInitialColumn = -1; | ||
| } | ||
|
|
||
| private static final boolean RESTORE_PRIOR_SELECTION_AFTER_QUICK_SEARCH = false; |
Contributor
There was a problem hiding this comment.
What is the idea here? Is this a fancy way of commenting out code?
Contributor
Author
There was a problem hiding this comment.
Oh, sorry I left that in. I'll remove it...
(Yes, fancy way to comment out code, especially when I need to experiment with different UI behaviors for a while before deciding what works or not. It also survives later refactoring.)
Member
|
moving to NB29 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Quick search is the little search bar that pops up when you start typing in various NetBeans explorer view components:
This PR unifies the search bar behavior in OutlineView, TreeTable, and ListView, with some adjustments and bug fixes. Mostly the search bar should work like a search bar in any other app, e.g. Chrome. Some common alternative keystrokes are handled for Find Next/Previous.
Details: