Bug 513299 - [UI polishing] Entry selection state is hard to predict after using the "Filter ..." action
Summary: [UI polishing] Entry selection state is hard to predict after using the "Filt...
Status: REPORTED
Alias: None
Product: dolphin
Classification: Applications
Component: view-engine: general (other bugs)
Version First Reported In: 25.08.3
Platform: EndeavourOS Linux
: NOR minor
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-12-13 16:01 UTC by ulterno
Modified: 2025-12-13 16:01 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ulterno 2025-12-13 16:01:24 UTC
SUMMARY
Press enter after using the filter ("Ctrl+I" or "/" by default) and you (user) now don't know which of the entries (of the filter output) is selected. Then after using the arrow keys to change the selection, you might know which one is (and was) selected.

In case the first/last entry is selected, then you (user) might require pressing 2 keys before finding out which one is selected.

STEPS TO REPRODUCE
1. Open a directory with multiple entries in Dolphin
2. Use the "Filter ..." action ("Ctrl+I" or "/" by default)
3. type a string that ends up matching multiple entries and press enter
4-A. Press enter a second time to find out (and activate) whichever entry was selected
4-B. Press up/down keys (right/left too, in case you are using a view with 2 dimensional entry placement) to find out which entry is in focus
4-C. The entry in focus was previously selected and now is also selected, so no problem

OBSERVED RESULT
- In case of 4-A, you (user) don't know which entry was selected, until you activated it. Undesirable 1.
- In case of 4-B, you (user) might not know which of the entries is selected until interacting with the selection space. Also, if the selection ends up being either the first or the last entry, you might require pressing twice before you know which one is selected. Undesirable 2.

EXPECTED RESULT
The selected entry at the end of step 3 is always predictable and preferably visible (so no need to predict).

SOFTWARE/OS VERSIONS
Operating System: EndeavourOS 
KDE Plasma Version: 6.5.3
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.1
Kernel Version: 6.17.9-arch1-1 (64-bit)
Graphics Platform: Wayland

ADDITIONAL INFORMATION

- This is not an accessibility issue, but ends up being a speed issue and is mildly frustrating when it happens all the time. I think I remember having something similar happen on Windows Explorer
- I noticed that the selected entry ends up being closer to the entry that was selected before using the filter.