-
Notifications
You must be signed in to change notification settings - Fork 28.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Common input box with filters #156179
Comments
Love that we are tackling this problem! From a design perspective, I think we can establish some principles for how the interactions should work:
Things that are unclear so far:
|
Here are what each of the inputs called out above are built from, plus the quick pick which we also want filter support for. Text editor
Terminal
Webview
Problems
Notebook
File explorer
Quick pick
|
TogglesText editor, terminal, webview, notebook
Filter toggleFile explorer implements the filter as a toggle as above
Filter dropdownNotebook and problems uses an Notebook:
Problems:
|
After looking into how everything works, here are my proposed changes. Let me know what everyone thinks.
@misolori I don't see any reason to make them look differently? Do you have an example of why this would be good? |
I like those proposals
The reason why I bring this up is that some find widgets have resize handles and some don't while others have a grabber to move it around. Not sure if this is a big deal but what came to mind when writing that. |
@Tyriar I like where we are heading towards, here are some of my thoughts for the proposal above
👍 for separating them, and I'm in favor of I'm not sure about if we are calling them Toggle/Filter, as Toggle is referring to the UI/UX, while Filter is referring to the functionality.
We can bring this to UX sync. I think in the long run we want to make it Filter/dropdown then we can introduce semantic search scopes (search in comments/strings/code). cc @alexdima @hediet . |
How about
I'm not sure we're currently that strict wrt options vs scopes. For the terminal anyway we're not sure whether we're going to have a toggle or a filter yet and the decision is currently coming down to are we able to get an icon to represent fuzzy search. I see all toggles and filters are just search options and/or modes, the main differentiator for me is whether they're important enough to be in the list vs in the filters dropdown. With that said, maybe we should be strict about this and make "Toggles" = options/modes/how something is searched, and "Filter Toggles" = scope/where/what is searched? @misolori thoughts? |
This makes good sense. If we are not trying to differentiate the functionalities of options in the list and the ones in the dropdown, then their difference is UI (where they get rendered), which is similar to Toolbar/ActionBar's primary/secondary grouping. |
To the user, it doesn't make much difference if an option is part of the input or in a dropdown, they are just "options", so I agree with this. I think in order to move into a dropdown there needs be more than one option. |
UX sync feedback:
|
Let's start one to ensure others who use find in selection in the team and Editor folks are aware of the coming UX changes. |
This makes it distinct from the common dropdown icon. Part of #156179
I tried this and had a bit of trouble making it nice. I suggest revisiting making it generic when we next look at adopting the dropdown in another |
With Find Widget introduced in File Explorer and Notebook Editor, we now have multiple implementations for input box with multiple filter/toggles. We reused
FindInput
which has 3 built-in filters (caseSensitivity
,wholeWord
andregex
) and had to add additional filters in our own ways. File Explorer and Notebook handles this differently and there isn't a clear path of how they can be unified and how other input box users can adopt this in the future.In addition, Problems panel and Terminal recent commands have their own input box with a single filter, which are not inherited from find input.
Variations
Text Editor
Terminal
Webview
File Explorer
Notebook
Problems
Proposal
The input boxes from find widgets shown above all derive from the original
FindWidget
in Monaco, which only has 3 builtin filters and they are no longer universal as not all embedders have the capability of implementing all of them. Embedders also have the need to the extend the filters which is not well supported, leading to the fragmentation of the find widgets.The proposal here is experimenting if we can introduce a generic
input
box with dynamic filters support at thebase/platform
level (not fromeditor
orworkbench
). The common features are:The UI for it can be a mix of the input boxes from File Explorer and Notebook, and embedders can contribute dynamic filters and declare how they should be rendered (as Toggle or Dropdown) statically.
A draft for the interfaces of the new input box and its filters:
The input box in the Notebook Find Widget can then be declared as
cc @joaomoreno @Tyriar @andreamah @mjbvz feedbacks welcome!
The text was updated successfully, but these errors were encountered: