Search dialog should become a search view which is not blocking

[vogella]

The blocking search dialog has certain disadvantages:

• You can not copy text from the IDE into this blocking dialog
• It blocks the view to the text
• It cannot be left open for later usage, this would be nice option if you do frequent search and replace operations

I suggest we move this dialog to a part, this way the user can still detach it if desired.

In theory it should be easy to do this change, we just replace the dialog with a part implementation.

[laeubi]

Instead of a complete new view, maybe this could be incooperated into the "Search Results"?

[vogella]

@laeubi also a valid option but most likely more complex as the Search view can also be filled via other means (IIRC).

[laeubi]

the Search view can also be filled via other means

Yeah but maybe it would make sense to have a "centralized" approach then to make those option available (non blocking), e.g. what I can think of is to have a textfield for the search, then on the left i can choose the type (E.g. File Search, Git Search, Java Search...) and on the right a "configure" button that opens a flyout to show the other options of the search (like when you minimized a view). Just a rough idea... having just another view might be confusing as actually they are closely related.

[vogella]

Whoever decides to work on this can select the approach. :-)

[merks]

What about just making it non-modal and making sure you can't open it more than once (just like the Find dialog).

I don't like the view idea at all.

[vogella]

What about just making it non-modal and making sure you can't open it more than once (just like the Find dialog).

That would be already an improvement, like I said: Whoever decides to work on this can select the approach. :-)

I don't like the view idea at all.

Why?

[mickaelistria]

I'm also not fan of a view in order to configure things. Dialog are semantically good to capture a user request, a view is good to get a view of something. Using a view to capture user input seems awkward to me.
However, unifying search request and search result in the same view would be nice; but I'm unsure we'll manage to build something that would be as easy to manipulate. Such a unified view would basically show the complexity of search request and search results at the same time; users would feel overwhelmed.

From here, I agree with @merks that the issues listed in the initial comment don't seem to mandate a view, and would be solved by simply making the dialog non-modal.

[jukzi]

As i change the search text much more frequent then the other options i propose to just add a small input field for that text.

[vogella]

Vscode search is nice, without replace:

with replace