The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback:

• It has to manually adapt to movements of the parent shell or the target part/widget
• It has to manually hide and show depending on visibility changes of the target part/widget
• It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc.
• It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there.

This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. With this change, when the overlay has focus, general shortcuts for the editor (such as opening types/resources but also undo/redo) still work, while content specific shortcut (e.g., comment out current line) are disabled.

Fixes eclipse-platform/eclipse.platform.swt#1447

Fixes #2099

Fixes #2246

Issues to be Resolved Before Merging

• Test failures on Linux need to be investigated

Known (Accepted) Issues / Drawbacks

• Proper handling of shortcuts requires the disablement of key bindings for the target text editor in order to (1) react to shortcuts at all and (2) in order to not execute unintended commands in the editor, such as commenting out a line while the overlay has focus. The implementation to achieve this is adapted from the breadcrumb implementation, which is kind of hacky but currently the only way I see to do this.
• Two of the shortcuts had to be changed due to conflicts with other shortcuts that can now be accessed from within the overlay. On the contrary, all shortcuts registered for editor, such as opening types or resources, are now accessible from within the overlay, which may be considered a benefit.
• For the other composite of the overlay, custom color handling had to be implemented, because it will usually be embedded into a StatusTextEditor containing a StyledText that uses a custom way of coloring as well, which is then inherited by the overlay. In order to have a consistent look, the colors of the outer composite of the overlay have to be retrieved and set in a custom way.

WiP

This is work in progress. At least the following is not working:

• Cursor: the cursor is shown according to the contents of the target widget, not according to the widgets in the overlay. I.e., on a button still the text cursor is shown.
• Shortcuts: shortcuts do currently not work as they are processed by the target widget and do not reach the overlay. Considering Find/Replace Overlay: Allow rebinding shortcuts #2015, we may directly implement the shortcut as actions that can be reconfigured.

Despite these problems that may require some additional effort, the overall design and integration with this approach makes more sense to be, as the overlay is really "integrated" into the target widget, as it is supposed to be. It gets rid of all the additional functionality to manually update position, size and visibility state according to changes of the target widget.

How it looks

This is how it looks on Ubuntu using Wayland: