Mw find replace overlay

[Wittmaxi]

No description provided.

[HeikoKlare]

I have taken an initial look at the functionality. Overall, it already looks quite nice!
Still I have some initial findings. I will have another look once the essential bugs are fixed. I would propose to address the "unexpected behaviors" and the "todos for now" before asking the community for feedback, so that they can focus on whether the dialog behaves as expected from a user/UX perspective.

Unexpected Behaviors

• Pressing ENTER in the replace field does only perform a search but no replacement. I would expect it to replace the current selection and not require ALT+ENTER to be pressed.
• When the dialog is open but focus is in the text editor, pressing CTRL+F will not move focus to the dialog but will close it. I would expect focus to move to the dialog.
• When closing the dialog via ESCAPE, it will require CTRL+F to pressed twice to open it again (because of the previous point).
• I can create multiple replace inputs. This can be achieved by pressing TAB and then ENTER from within the replace input box (even multiple times):
  
  It then takes the input in the last opened text field for replacement, even when clicking the replace button in some other row.

Todos For Now

• We should provide a button to switch to the pre-existing dialog. This is particularly important for the PoC because it eases comparison of old and new behavior, as you can easily switch between those functionalities.
• May also for later, but could also be great for PoC and/or demo at EclipseCon: Dialog is only shown in the currently active view but should shown until it is closed.

Todos For Later

They should at least be documented as things to still be addressed in the feature development when starting a PoC PR:

• Replace/Find function should be provided in some way (i.e., the next find result is selected after performing a replacement).
• We could think about having a possibility to close the dialog not only via keyboard but also via a close button ("X") or the like.
• My feeling is that the UI will look cleaner if the two text boxes have equal width even if a different number of buttons is placed next to them.
• Resizing is kind of broken at some point when the dialog becomes too small:
  
• When the width of the dialog is changed while the containing view is too small to contain the "fully-sized" dialog, the graphics canvas is not properly flushed so that artifacts from the previous size remain after repaining. It is hard to make a screenshot (I can take a video if necessary), but is easy to reproduce when making the containing view quite small.

[HeikoKlare]

From my point of view, the state it great for presenting it to the community. There is only one little thing I would propose to address before submitting a draft PR to discuss the implementation.

• When the overlay is closed while the "replace" part is open, then the overlay is opened again (via CTRL+F), then the "replace" part will not open upon clicking "+". You need to click expand, collapse, expand until it opens. This is probably related to some old state of the overlay still being present.

And there are two minor additions that you should put on the list to be tracked to be addressed later (and mentioned in the initial PR):

• I would expect pressing ESCAPE within the editor (not the overlay) to also close the overlay. But that's something I am absolutely open for discussion.
• When you do a search and then click "replace" multiple times, you have to undo as many times to go back to the original content. I would expect a "replace" to only be applied (and written to operation history) only once.