Use unified search input to filter in files

[raimund-schluessler]

Until NC 19 it was possible to filter the shown files and folders in the files app by the search string. With the unified search, this is no longer possible which makes it cumbersome to find a certain file or folder in a folder with many entries, especially since entries are loaded paginated.

The files app should just as well listen for the event emitted by the unified search and filter accordingly.

[jancborchardt]

Yeah, this would still be the expected experience. @skjnldsv are you aware of the regression?

cc @tobiasKaminsky since he mentioned something similar to me as well.

[skjnldsv]

Yeah, we decided we were ok with this in one of the calls.
As files are listed directly, there was no need for a double filtering

[tobiasKaminsky]

I dare to disagree…

• imagine if files search is slow(er) than the other providers, then you do not directly see files result
• imagine you are searching for "Home", which is 100% in same folder, but search result gives you >10, then it might not be within first 10 search results

[skjnldsv]

I dare to disagree

Not saying what is better or not, saying that was intended as discussed in the calls.
Whatever ya'll want to change I don't care, please do it. I have no preferences whatsoever.
As always, your call Jan, this is about ux! 👍

[PVince81]

Maybe the search result list could split the results in two parts: the local search results of the current app and the global ones.

If the unified search field would at the same time filter the file list it would feel strange as they are visually disconnected somehow. It would rather require another search field specifically on top of the file list, but seeing two fields might feel redundant. Or hide it behind a "filter files" icon with a dropdown showing the box. Having it closer to the file list would make a visual connection.

[andreas-p]

Per feedback from users, the search result list is felt to be awfully small. This usability aspect was covered in #24029, and shouldn't get lost.

[juliusknorr]

@jancborchardt I was looking into reintroducing the local folder filtering however there is a quite big UX issue in my oppinion as the search input is now hidden in the popover and once that is closed there it is not really clear how to cancel the filtering or what query is currently active:

Compared to the old version where the input was always visible:

Any good idea how we could solve that?

[skjnldsv]

We could display the search text left to it, still within the button?

[tobiasKaminsky]

Similar is already in /settings/apps, where one can filter in popup also current app list, closes popup, filtering remains and one has to click on search to cancel within popup.

@skjnldsv symbol next to deck then should have a cancel, or? like:

[biva]

I like your solution @tobiasKaminsky

[StCyr]

Maybe the search result list could split the results in two parts: the local search results of the current app and the global ones.

At first I thought it would be very easy to implement, until I realised File's unified search provider has no ways to know from which folder the search was triggered 😢

[StCyr]

Any good idea how we could solve that?

I see 2 possibilities:

1. Implement a 'local' search totaly independent from the unified search. Example:
   
2. Update File 'Search provider to list local files first (but how could File 'Search provider know from what folder it has been called?)

[StCyr]

Similar is already in /settings/apps, where one can filter in popup also current app list, closes popup, filtering remains and one has to click on search to cancel within popup.

That would be cool

[Spartachetto]

It seems to me that the UI part of this issue is related to #27078

[PVince81]

seems this PR brings it back: #26841