SUMMARY The search bar disappears when the current view changes, and this cannot be changed. Almost all other file managers allow it to remain always visible, or don't even provide the option for it to dynamically hide, so this is unintuitive. STEPS TO REPRODUCE 1. Enable the search bar. 2. Switch directories. OBSERVED RESULT It disappears when the view changes: https://discuss.kde.org/t/can-i-keep-dolphins-search-bar-permanently-visible/5521/4?u=rokejulianlockhart EXPECTED RESULT It should remain visible. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230922 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.4-1-default (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor Memory: 30.5 GiB of RAM Graphics Processor: AMD Radeon RX 5700 Manufacturer: ASRock Product Name: X670E Taichi ADDITIONAL INFORMATION Not being able to do so must seem very strange for Windows users.
>Almost all other file managers allow it to remain always visible, >or don't even provide the option for it to dynamically hide, >so this is unintuitive. This workflow doesn't make sense to me. If a user uses the search feature to find a file and then opens a folder from there, why would they want to search again in the folder they just found? Hiding the search box seems to be the more sensible behaviour to me. If it is about "always being able to search", this doesn't make sense to me either, because it is one click either way: Either one click to focus the search field or one click to activate the search from the "Search…" toolbar button.
(In reply to Felix Ernst from comment #1) > >Almost all other file managers allow it to remain always visible, > >or don't even provide the option for it to dynamically hide, > >so this is unintuitive. > > This workflow doesn't make sense to me. If a user uses the search feature to > find a file and then opens a folder from there, why would they want to > search again in the folder they just found? Hiding the search box seems to > be the more sensible behaviour to me. > > If it is about "always being able to search", this doesn't make sense to me > either, because it is one click either way: Either one click to focus the > search field or one click to activate the search from the "Search…" toolbar > button. I use the search constantly. I don't want to have to constantly toggle it. Imagine having to unhide your internet browser's omnibox every time you wanted to search.
(In reply to third="Beedell", first="Roke", second="Julian Lockhart" from comment #2) > I use the search constantly. I don't want to have to constantly toggle it. But it is one click either way, right? Either you click on the search box or you click on the search button which focuses the search box? There is definitely a difference when it comes to the size of the click target though: If the search is already opened, the big search box is much easier to click than the search button. On the other hand you as a user can make the search button bigger by having its text always shown. Is this about the size of the click target? Or do you dislike how the view resizes itself to also fit the search box and you would rather have the user interface to move less? Something else? > Imagine having to unhide your internet browser's omnibox every time you > wanted to search. I don't think this is a good comparison. As I said, this would be one click away either way. The only reason I wouldn't want the omnibox to hide is that it is also a location bar that shows essential information about where one is. This, however, isn't true for the search box after changing view location in Dolphin. We don't hide the location bar in Dolphin either for that reason.
> But it is one click either way, right? Either you click on the search box or you click on the search button which focuses the search box? There is definitely a difference when it comes to the size of the click target though: If the search is already opened, the big search box is much easier to click than the search button. On the other hand you as a user can make the search button bigger by having its text always shown. > > Is this about the size of the click target? Or do you dislike how the view resizes itself to also fit the search box and you would rather have the user interface to move less? Something else? Not that I'm aware of. I use Ctrl+F to invoke it (I wasn't actually aware that a search button existed) so those considerations aren't important to me. > I don't think this is a good comparison. As I said, this would be one click away either way. The only reason I wouldn't want the omnibox to hide is that it is also a location bar that shows essential information about where one is. This, however, isn't true for the search box after changing view location in Dolphin. We don't hide the location bar in Dolphin either for that reason. That comparison isn't correct, because I somewhat misled you – I don't actually use the omnibox for searching in Firefox. I use its dedicated search bar, available via Customization. I mentioned the omnibox in case the respondent wasn't aware that a separate search bar was available, or was more used to Chrome. I can't really see why this would be controversial – the ability to prevent the search bar hiding could just be implemented as an option, right? I doubt that I'm the only one with this issue, because the reason I reported this was that my brother, a user of Windows 11, mentioned that I kept reopening the search bar every time I searched, which he found absurd. Since then, I've been noticing it, and it's bothered me.
>I can't really see why this would be controversial It only becomes controversial if there is no compelling reason to have this behaviour even as an option. If we add settings without a reason we end up with a huge amount of settings very little of which are actually useful to users. Currently it seems like this is only about personal preference and doesn't effect the usability for you at all. If I am wrong about this, that would be fine as well! But we will need to figure out the exact reason or we won't be able to identify the core of the issue, and what might be the best solution to that problem. >I kept reopening the search bar every time I searched, >which he found absurd. Since then, I've been noticing it, >and it's bothered me. This is the only reason you have given me so far. I disagree with absurd: It saves screen space in situations in which one isn't searching. It also saves people the trouble of manually hiding the search after they have already found what they were searching for. >I use Ctrl+F to invoke it (I wasn't actually aware that a search button existed) >so those considerations aren't important to me. That's even better then because Ctrl+F will always open the search and focus the search field. Even if you had the search bar visible before you start typing a search term, you would still press Ctrl+F to get focus on the search field. From what you are saying it seems like the usability wouldn't improve by keeping the search visible.
> It also saves people the trouble of manually hiding the search after they have already found what they were searching for. But it doesn't for me. It's the opposite. *That*'s the sole reason that I have provided, because it's the sole reason I want it. What you stated is the sole reason I've provided isn't really a reason, and I'm thus not certain why you've interpreted it as such, especially since I've so clearly stated why this is more fundamentally desirable.
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/623
Git commit 4d018e1c3cd5211c82cfe42a250956adfb47747b by Felix Ernst, on behalf of Amol Godbole. Committed on 05/10/2023 at 11:43. Pushed by felixernst into branch 'master'. DolphinViewContainer: Keep search box open when URL is changed The search box was being automatically closed whenever the URL is changed. Keep the search box open if no search text had been entered when the URL was changed. M +4 -2 src/dolphinviewcontainer.cpp https://invent.kde.org/system/dolphin/-/commit/4d018e1c3cd5211c82cfe42a250956adfb47747b