The «Find» bar is really useful in some situation but the filter bar is really fast and does not search recursively (which in some case is a really useful feature). But the filter bar is hard to find, and it’s difficult to understand the difference between «Find» and «Filter Bar» for most users. Merging the two features (by adding a «Don’t Search Recursively» checkbox for example) enable us to use the «Find» bar features while filtering. We can also switch from one to the other kind of search mode easily if we find to much or not enough results. To ease transition, we can keep the actual shortcuts: the «Find» shortcut acts as before, and the «Filter Bar» shortcut opens the «Find» bar with «Don’t Search Recursively» already checked. Reproducible: Always
> it’s difficult to understand the difference between «Find» and «Filter Bar» for most users Are these user survey results published anywhere?
> Are these user survey results published anywhere? Nowhere, but I think I’ve good reasons to presume that: * I’m «an advanced user», and I didn’t know the difference between the two before trying the two. With one «Find» function, like any other application, no questions from users, they get it immediately. * «Find» and «Filter Bar» can actually be interchanged. «Find» doesn’t mean recursively, «Filter» doesn’t mean the opposite. «Find» is collecting the entries that match the pattern, «Filter» is take the whole entries and remove the ones that don’t match — it’s the same thing. * Filtering **is** (a limited form of) searching, so it’s harder to remember (and harder to find, because the user can think it’s a function he already know). Typing, obtaining results, it’s the same thing. Why two functions for the same thing? It’s counter-intuitive. I don’t have numbers, but I think it’s pretty obvious that having two different search functions is confusing, require duplicating code and is less powerful.
Thanks for the suggestion. (In reply to comment #2) > * «Find» and «Filter Bar» can actually be interchanged. «Find» doesn’t mean > recursively, «Filter» doesn’t mean the opposite. «Find» is collecting the > entries that match the pattern, «Filter» is take the whole entries and > remove the ones that don’t match — it’s the same thing. Sorry, but it's not the same thing at all. "Find": * can not only match patterns in the file name, but also in the file contents * has additional options if Nepomuk is enabled * can be quite slow. "Filter": * matches the file names which are currently shown in the view. Therefore, it is always very fast. * The filter can be made persistent by clicking the "lock" in the filter bar. You can then navigate to other folders and still use the same filter. * can even be combined with the "Find" functionality, to filter the search results by name. I know from user feedback that both features are used very frequently. It should be obvious that many people will be upset if the fast filtering is dropped. Even more so if the only benefit is that we can remove one menu entry. One more thing to support the fact that the speed of the "filter" feature might be crucial: in former times, I frequently used Alt+F2 to start applications. However, many features have been added to the dialog that pops up when pressing Alt+F2 since then, and now it sometimes takes several seconds to start up. Therefore, I don't use it any more.
> Sorry, but it's not the same thing at all. > […] I know the difference between the two features. > I know from user feedback that both features are used very frequently. It should be obvious that many people will be upset if the fast filtering is dropped. Even more so if the only benefit is that we can remove one menu entry. Maybe I was unclear: it’s not about removing fast filtering. The basic idea is to add an option in Find to Filter, something like «Only Currently Displayed Items» which is enabled by default when using Ctrl+I, which is (fast) filtering. It gives us the ability to use the «Find» semantic searching options, without having to deal with two different text area («Find» and «Filter Bar»). And we can even search in currently displayed files’s content (which is now impossible). In fact, filtering is just «Find», without any semantic searching options enabled, and only in currently displayed items. So why it must be a completely different feature, instead of just an option of generic one? > One more thing to support the fact that the speed of the "filter" feature might be crucial: in former times, I frequently used Alt+F2 to start applications. However, many features have been added to the dialog that pops up when pressing Alt+F2 since then, and now it sometimes takes several seconds to start up. Therefore, I don't use it any more. You can disable plugins in Krunner. Here we also have the choice: doing slow search everywhere, slow search only from here, and quick search only in currently displayed items.
(In reply to comment #4) > The basic idea is to add an option in Find to Filter, something like «Only > Currently Displayed Items» which is enabled by default when using Ctrl+I, > which is (fast) filtering. Adding options harms usability and makes the code harder to maintain. Please provide evidence that having separate "Find" and "Filter" features really causes problems for a large user group before we continue the discussion. Thanks.