HeikoKlare
commented
1 year ago Proposal: modern and less intrusive Find-Replace
Maybe say "better integrated" instead of "less intrusive" (or what exactly do you mean by "intrusive" here?
Proof of concept implemented in my Fork of eclipse.ui
Problem
User-Interface
The current solution opens a Modal on keypress Control + F - prompting a user to enter a string for finding and optionally a string to replace the currently found string with. The status quo also has multiple options for searching which are available by selecting the appropriate checkbox.
The modal can be disturbing while programming
- The modal requires a mental context switch
- Not only a mental one but a switch between windows in general.
- You could add here that the opened dialog window is on top of the workbench window, so that it can easily hide important controls. An integrated control will not overlap with important content.
- You could add that you do often not know which view the dialog is currently referring to. If you have two text editors side by side and switch between them, it is not easy to see (or mentally follow) which one was activated last and will be used for search (or even worse, for replace).
- In many cases, the user "just want's to search", not needing too many options. I personally really like using vim's search feature for it's simplicity.
This is a valid point, but that is something that you could also achieve with a redesign of the current dialog. Maybe you could generalize the problem statement from "what are the drawback of the modal dialog" to "what are the drawback of the current find-and-replace functionality". Then one aspect is the functionality being provided via a dialog and another is the missing customizability with respect to the current needs.
- Searching forward and backwards requires to select the correct radio button and then pressing "search" - which is not intuitive and hindering in many workflows
Unification
A lot of views could benefit by reusing the same Find-Replace mechanism. For example, a user might want to search through problems, through bookmarks, through the package explorer or through the outline using Control + F.
This is even more not an issue of the current implementation using a dialog but a missing integration of the find-and-replace functionality into views.
Solution
I would start here with a statement that the solution will be twofold:
- Provide a hook for view parts that can deliver their own search provider, which is then (generically) used to instantiate a find-and-replace inline control (or dialog) to address the issue of unification.
- Provide an alternative UI for the search functionality that uses an inline control rather than a dialog (as in the screenshot of the PoC above).
Look and Feel
It would be good to start with an abstract description of the solution space for the look and feel. This includes:
- Design goals, such as having the control at a defined or customizable position within the workbench rather than in a dialog on top of the workbench
- Design options, such as having a composite at the top or bottom of the view to search in, or having a composite as an overlay to the view (like in VSCode). This should be a point for discussion and request for feedback; or having search and replace text boxes horizontally or vertically stacked.
Then you can proceed with a concrete example / proposal for how the UI could look like. Mention here that it is only a PoC for demonstration, i.e., the look and feel is not fixed, the icons can be replaced etc. to fit into the general Eclipse look-and-feel.
The proposed solution consists of an inline-search bar, that pops up from below the text-editor.
- input bar - active by default when pressing Control + F , automatically highlights the occurrences in the text while the user types (like the behaviour in VSCode). If Text is selected when the inline-dialog is started, the content of the selection is entered into this field by default. When pressing ⏎ Enter, the next occurence is found, in the direction specified by the buttons
3and4- The amount of occurrences in the current text
- "Search up": performs a single search up and sets the search direction (for ⏎ Enter)
- "Search down": performs a single search down and sets the search direction (for ⏎ Enter)
- "Search whole word": toggles
- "Case sensitive search": toggles
- "RegEx search": toggles
- "Open replace-dialog": toggles
- Input bar for replace
- Replace next occurrence (direction defined by the arrows from the search bar)
- Replace all
- Toggle replace dialog off
Additional
As a proof-of-concept, the same dialog was implemented for the
Problems Viewto show that this feature can easily be extended to other views. The Problems-view does not allow for replacing, for example, so the search-bar does not show that as an option.
As part of the interface-design, each view will have to specify which "search modes" it supports (See Search-providers)
Maybe better directly call this "search provider" rather than "search modes", as the provider will define more than only modes to operate in (such as how to find things within a specific view and how to select them). In addition, say that this is supposed to be optional, such that a view can define a search provider (and for text editors there will be a default implementation of such), but there is no need to do so and then the view will not provide search functionality with that mechanism.
Design (Engineering)
I would add one point on design concerning shared code between the old dialog and the new inline visualization. I would state that the goal is to extract shared business logic into a dedicated class and have two UIs accessing that same business logic. Then:
- Both visualizations behave consistently. Otherwise users will be confused about differences in their behaviors
- Both visualizations benefit from the same bugfixes and other improvements.
Inline-toolbar
This proposal introduces an "inline popup toolbar", which can later be used by other features which are currently implemented as modals, for example a new refactoring. Views that provide support for such an inline toolbar, can inherit from
IInlinePopupToolbarProviderwhich specifies functions for creating the toolbar composite and closing it.
This is not an inherent decision concerning the actual feature to implement but a decision that enabled further improvements that are no directly related to the find-and-replace functionality. I would separate this from the design of the feature itself, so put it into some other category such as "Additional Remarks" or put it into the existing "Further ideas".
Search-providers
Each view should be able to specify it's search-providers and it's search-options. When opening the FindReplace-popupbar, the the bar will query the view to build it's UI.
I would clarify that the inline search requests a search provider (along with a UI renderer) from the view. Probably, the UI renderer will be the thing that is shared across most views, while the functional search provider may differ depending on the view type.
Further ideas
The old Dialog
In order not to prescribe any workflow, this search-bar will be configurable, rendering the old search-bar still available by selecting the right Preference. In addition, it is fathomable that the current search bar is given a button that switches to the "old dialog" - it can even be the case that most search-options are dropped from the search bar, making the "old dialog" the more powerful search option while the popup-bar-search is a lightweight and non-intrusive "quick search".
I would put the consideration with respect to the old dialog into the solution description. Dealing with legacy is fundamental in a framework like Eclipse, so it must be integrated into considerations for new features. I would explicity state the following proposal in the solution description:
- The old dialog will stay as default, the new can be enabled via preference
- The new implementation could be enabled by default for specific products (such as the IDE)
- Option for discussion: both implementations could have buttons to switch to the other representation (i.e., to modify the preference).
More search options
- A new search-option could be added to perform an AST-search on a Java-file
You should mention that this could be a benefit of having view-specific search providers (not of having an inline search visualization). In addition, you should clarify that such extensions are not part of the current design. It would require to not only "configure" a search provider but to define completely different types of search provider with according UIs. The question is whether that should really be a central, shared functionality, or whether such specific searched should not be own views, such as having the Java search (Strg + H) represented in a dedicated view rather than a dialog. I would actually not be in favor to have such a thing embedded into the "simple search" but to keep it separated like the (view-independent) full-text search as well.
Different Design
The current design borrows from IntelliJ's search dialog. We can also opt to implement this feature in the same way as Microsoft's Visual Studio code does.
Rather than saying that the current design is from IntelliK and could instead be taken from VSCode, you could rather say that the design is inspired by IntelliJ but that is part of the discussion to agree on the functionality / look-and-feel that we want to have and that we feel fitting for Eclipse, which may also incorporate different design decisions from other tools such as VSCode.
Wittmaxi
Proposal: modern and less intrusive Find-Replace
Proof of concept implemented in my Fork of eclipse.ui
Problem
User-Interface
The current solution opens a Modal on keypress Control + F - prompting a user to enter a string for finding and optionally a string to replace the currently found string with.
The status quo also has multiple options for searching which are available by selecting the appropriate checkbox.
Unification
A lot of views could benefit by reusing the same Find-Replace mechanism. For example, a user might want to search through problems, through bookmarks, through the package explorer or through the outline using Control + F.
Solution
Look and Feel
The proposed solution consists of an inline-search bar, that pops up from below the text-editor.
1) input bar - active by default when pressing Control + F , automatically highlights the occurrences in the text while the user types (like the behaviour in VSCode). If Text is selected when the inline-dialog is started, the content of the selection is entered into this field by default. When pressing ⏎ Enter, the next occurence is found, in the direction specified by the buttons
3and42) The amount of occurrences in the current text 3) "Search up": performs a single search up and sets the search direction (for ⏎ Enter) 4) "Search down": performs a single search down and sets the search direction (for ⏎ Enter) 5) "Search whole word": toggles 6) "Case sensitive search": toggles 7) "RegEx search": toggles 8) "Open replace-dialog": toggles1) Input bar for replace 2) Replace next occurrence (direction defined by the arrows from the search bar) 3) Replace all 4) Toggle replace dialog off
Additional
As a proof-of-concept, the same dialog was implemented for the
Problems Viewto show that this feature can easily be extended to other views. The Problems-view does not allow for replacing, for example, so the search-bar does not show that as an option.As part of the interface-design, each view will have to specify which "search modes" it supports (See Search-providers)
Design (Engineering)
Inline-toolbar
This proposal introduces an "inline popup toolbar", which can later be used by other features which are currently implemented as modals, for example a new refactoring. Views that provide support for such an inline toolbar, can inherit from
IInlinePopupToolbarProviderwhich specifies functions for creating the toolbar composite and closing it.Search-providers
Each view should be able to specify it's search-providers and it's search-options. When opening the FindReplace-popupbar, the the bar will query the view to build it's UI.
Further ideas
The old Dialog
In order not to prescribe any workflow, this search-bar will be configurable, rendering the old search-bar still available by selecting the right Preference. In addition, it is fathomable that the current search bar is given a button that switches to the "old dialog" - it can even be the case that most search-options are dropped from the search bar, making the "old dialog" the more powerful search option while the popup-bar-search is a lightweight and non-intrusive "quick search".
More search options
Different Design
The current design borrows from IntelliJ's search dialog. We can also opt to implement this feature in the same way as Microsoft's Visual Studio code does.