[Modern Find/Replace] Implemented Find-Replace Overlay

[Wittmaxi]

Modern Find-Replace Overlay

newly introduced Overlay in dark theme

newly introduced Overlay on the bottom of the screen, used to perform a replace-operation.

at the top of the screen, with some search-options enabled

What are we addressing (copied from #1090)

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 switch to a new window
  • The modal can hide important controls while open
  • It is not clear which View the Find/Replace-Dialog is bound to. This becomes an issue, when two editors are opened side-by-side.
• 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.
• Searching forward and backwards requires to select the correct radio button and then pressing "search" - which is not intuitive and hindering in many workflows

Showcase

2023-10-05_11-21-40.mp4

[github-actions]

Test Results

 1 812 files   1 812 suites   1h 35m 0s ⏱️
 7 634 tests  7 405 ✅ 228 💤 1 ❌
24 063 runs  23 313 ✅ 749 💤 1 ❌

For more details on these failures, see this check.

Results for commit 3a2e413.

♻️ This comment has been updated with latest results.

[jukzi]

I like the idea!
But the implementation does not feel perfect yet:

1. The Minus Symbol is not at the same location as the Plus symbol. so expand/collapse does not feel right
2. The text "classic find/Replace" takes too much space. I would prefer a small button
3. i can't move the Popup around. It may hide some text in the editor. Should be either a) moveable (mouse drag) or b) outside the Editor content area. I would prefer to have it at the Bottom left - not as an overlay but like the statusbar.
4. i am missing the last searched/replaced words in a dropdown. I am using that a lot and its a real show stopper for me to not have access to the last searches.
5. The Match-Case Symbol does not feel intuitive. Better a capital letter next to an lower letter.
6. The colors feel a bit odd. i don't know what exactly is wrong. But most likely the grey border around the search input. Especially letters like "j","g" that have some drawing below the writing line do touch the border below, while Capital letters do not touch the upper border
   
7. after resizing the input field is sometimes distorted / text drawn to much left
   
8. it currently doe not work well in console view (wrong location, too small, +/- not working):
   
9. it should replace the search in the Javadoc search
10. error "Widget is disposed"

org.eclipse.swt.SWTException: Widget is disposed
	at org.eclipse.swt.SWT.error(SWT.java:4918)
	at org.eclipse.swt.SWT.error(SWT.java:4833)
	at org.eclipse.swt.SWT.error(SWT.java:4804)
	at org.eclipse.swt.widgets.Widget.error(Widget.java:450)
	at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:369)
	at org.eclipse.swt.widgets.Control.isFocusControl(Control.java:1899)
	at org.eclipse.ui.texteditor.FindReplaceOverlay$1.performEnterAction(FindReplaceOverlay.java:128)
	at org.eclipse.ui.texteditor.FindReplaceOverlay$1.keyPressed(FindReplaceOverlay.java:159)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:171)

[Wittmaxi]

Thank you for your feedback, @jukzi.

In particular, 9) is related to this issue.

[jukzi]

Optically i like the "filter" bar in the Error Log View much more - below the editor it would be nice for searching:

[vogella]

Did we make any progress here? Would be a shame not to get this beautiful new UI into Eclipse.

[HeikoKlare]

@vogella Maximilian is still working on this. The first to merge is the refactoring in #1132. And then I hope that we can merge a first version of this new UI (probably to be optionally activated at that point in time) for 4.31 M1.

[Wittmaxi]

The layouting now happens in three stages:

1. Maximal width:
   Will stop growing at a certain width, such that it does not become too big (especially on large screens)
   

2. Compromise width
   The Toolbars are removed, making space for the inputs. Since all tools are still available through keybindings, we don't "lose" functionality per se, and you can still "quickly search" in your small editor. I made the assumption that users will not want to power-use the feature in an editor that was cast to the side and that users who want to perform harder operations that require the toolbar to be visible would also open the editor to long enough to display the entire find/replace-bar.
   
   

3. Worst-case compromise
   Every tool-button is discarded and the Dialog is resized to take up 90% of the width of the parent.
   You can still perform all actions and enable/disable the "Replace"-Feature using Ctrl+R
   
   

[vogella]

@Wittmaxi can you continue with this enhancement now that the refactoring is done?

[HeikoKlare]

can you continue with this enhancement now that the refactoring is done?

He is working on it, but it may still take some time due to limited time budget. We optimistically aim for a contribtion as soon as possible after 2024-03 freeze, so we have quite some time for evaluation in the development cycle for 2024-06.
We at least have to do these things for an initial contribution:

• Provide a configuration option via property (to select whether old dialog or new overlay shall be used)
• Fix a bug with overlay placement in different kinds of editors (current issue with the console view)
• Select / design proper icons and finalize the look&feel
• Conduct some intensive testing

[Wittmaxi]

I expect at least one Test to fail: The FindReplaceDialog-Test currently cannot test the default behavior since the "new Overlay" is opened by default. If this persists after I correctly parametrise the new Overlay, I might have overlooked a problem while merging.

[Wittmaxi]

@HeikoKlare @vogella very happy news!

I could fix another final milestone: the Overlay now binds to the constraints of Console's when opened on one (not yet perfectly...):

Here is a screenshot of the parameter used for selecting between Find/Replace-Methods:

The Find/Replace-Overlay is off by default (for now).

I have one doubt and need to check this:
What happens when I add a Listener to a Control in a PageBookView and the current Page changes? How can I retrieve that listener? Is that even necessary or will it just be destroyed? Do I risk some nullpointer-errors?

This is the relevant code:

	private void unbindListeners() {
		if (targetPart != null && targetPart instanceof StatusTextEditor textEditor) {
			Control targetWidget = textEditor.getSourceViewer().getTextWidget();
			if (targetWidget != null) {
				targetWidget.getShell().removeControlListener(shellMovementListener);
				targetWidget.removePaintListener(widgetMovementListener);
				targetPart.getSite().getPage().removePartListener(partListener);
			}
		}
		if (targetPart != null && targetPart instanceof PageBookView consoleView) {
			Control targetWidget = consoleView.getCurrentPage().getControl();
			if (targetWidget != null) {
				targetWidget.getShell().removeControlListener(shellMovementListener);
				targetWidget.removePaintListener(widgetMovementListener);
				targetPart.getSite().getPage().removePartListener(partListener);
			}
		}
	}

	private void bindListeners() {
		if (targetPart instanceof StatusTextEditor textEditor) {
			Control targetWidget = textEditor.getSourceViewer().getTextWidget();

			targetWidget.getShell().addControlListener(shellMovementListener);
			targetWidget.addPaintListener(widgetMovementListener);
			targetPart.getSite().getPage().addPartListener(partListener);
		}

		if (targetPart != null && targetPart instanceof PageBookView consoleView) {
			Control targetWidget = consoleView.getCurrentPage().getControl();

			targetWidget.getShell().addControlListener(shellMovementListener);
			targetWidget.addPaintListener(widgetMovementListener);
			targetPart.getSite().getPage().addPartListener(partListener);
		}
	}

[vogella]

Rebased onto master which contains the version bump for the test plug-in. Fingers crossed....

[vogella]

Next version bump #1939

[vogella]

Rebased onto the next version bump. Fingers crossed again...

[vogella]

@Wittmaxi org.eclipse.search.tests has test errors under Windows. Can you have a look?

[Wittmaxi]

@vogella I didn't write or modify this test, it is not related to my PR and I am very confident that the fail isn't a side-effect of my pr.

However, I could not find it in the issues - I have documented the random fail here: #1941

I cannot access my computer today, thank you for helping (finally!) merge this PR 😀

[vogella]

Thanks @Wittmaxi for documenting the failing test #1941

I merge this change now. Thanks for all your work @Wittmaxi and also thanks to @HeikoKlare and all others for reviewing this change very, very carefully.

[merks]

It's cool! And EMF's use of the find dialog still works too:

So cool new stuff works and old stuff also still works. Well done!!

[HannesWell]

Tried this out yesterday for the first time and it's really nice.

Can you please create a new and noteworthy for this new feature in https://github.com/eclipse-platform/www.eclipse.org-eclipse ?

[jukzi]

@Wittmaxi that message box looks somehow wrong. I guess it's the missing border and white bar at the bottom that makes it look ugly (win, Light default theme):

[HeikoKlare]

For the record: reported issue is addressed via #2188