Replace Find-And-Replace Dialog With Modern, Lightweight, Visually Integrated Search Bar

[HeikoKlare]

Current Behavior

The current search dialog in Eclipse quite outdated / has a bad UX and not intuitive to use. Some of the most important issues are:

• It provides all configuration options at once rather than providing the most important ones and allowing an extension to an advanced mode.
• It is a dialog on top of the UI that easily hides important controls/information of the workbench.
• It is connected to the currently active view so that it is no easy to see (and especially not fixed) in which view it searches.
• It is only propertly available for text editors and not for other kinds of views

Expected Behavior

A lightweight, extensible in-view search functionality that is obviously bound to a specific view, does not hide important information and can be provided for other views than textual ones.

The more sophistacated proposal is given in eclipse-platform/eclipse.platform.ui#1090.

Basic Increments

1. View-specific find-and-replace: Create an (optional) substitution for the existing find-and-replace dialog that is embedded into the view it is opened from (as an overlay) with a streamlined layout providing only basic functionality (with the ability to extend more advanced functionality on demand). A view shall be able to define whether it supports this in-view search and it shall provide a way to dynamically switch back to the old, view-independent search dialog.
2. View-specific search provider: Enhance views (ViewParts) by allowing them deliver a specific search provider for that view, so that only text but any kind of information visualized in a view can be searched in highlighted via a unified interface.
3. View-integrated find-and-replace: Allow to integrate find-and-replace functionality into views, i.e., to embed the functionality into a (non-overlapping) representation, such as a search bar at the bottom of a text editor. A view shall be able to define which kind of search visualization is uses.

[mickaelistria]

I think an even 1st increment is just to ship a (floating and placed as best upon text viewer) Search Bar variant of the Find and Replace dialog that is used by text editors.

[Wittmaxi]

Roadmap

Milestone 1

e.g., December 2023

Refactor FindReplaceDialog.java

This class mixes the functionality and the interface of Finding and replacing. To reuse this functionality, I want to extract the business logic into a separate FindReplacer-module which will be reused by the new find-replace-bar.
This step will NOT include any logic for polling views for their search-providers

Implement the overlay-based Find/Replace

(subject for debate)
I will implement the overlay-based Find/Replace as @mickaelistria suggested earlier. This will entail a different design that looks more like the one VScode currently uses and will incrementally approach a good solution that can be shipped with the December 2023 release.

Milestone 2

e.g., March 2024

Integrate into Layout

Using a new Composite inside of the View (like in the current solution), I will integrate the dialog into the Layout. This will happen as soon as possible, to give us a lot of time to find possible problems in integration.

Poll Views for search providers

Allow each view to give it's own search-providers to the FindReplacer using a new common interface for FindReplace

Implement the Find/Replace functionality in more views

[HeikoKlare]

Preparatory refactoring separating FindReplaceDialog UI from its business logic to be reused for new UI:

• [Modern Find/Replace] Refactor FindReplaceDialog eclipse-platform/eclipse.platform.ui#1132
• Move identification of find/replace operation success to status object eclipse-platform/eclipse.platform.ui#1501
• Rename status for find/replace from IStatus to IFindReplaceStatus eclipse-platform/eclipse.platform.ui#1503

Contribution of the the new overlay UI:

• [Modern Find/Replace] Implemented Find-Replace Overlay eclipse-platform/eclipse.platform.ui#1192