| dfaure | |
| ngraham |
| Frameworks | |
| VDG |
If the user types some text in the lineEdit and there's more than one
match in the model view, don't automatically select the first match, so
that if the user presses Enter/Return, we don't load the first result
as it could well be not what the user actually wants.
BUG: 400725
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
Why wouldn't you want the first result chosen when there's more than one result? If you enter a search term and get (say) 2 results and the one you want to select is the first one, this patch would regress that, no?
If there is more than one result, there is no way for the code to know which result the user actually wants; please see the test plan for an example of when this backfires.
Sorry but fixing the issue in the way you're proposing is a UI regression; it's just privileging one use case over another (the case where the first item is *not* the one you want to launch, vs the case where it is), and does not fix the underlying problem.
That underlying problem is that there is no way to use the keyboard to move the selection highlight between the results in the list the way, for example, KRunner does it: the left and right arrow keys move the insertion point in the search field, and the up and down keys navigate through the list of search results. That's the way it should be here IMO.
Right now the up and down arrow keys navigate through historical entries in the combobox which doesn't really make sense for the use case that this dialog supports. KRunner also has a search history but it isn't accessed in this way. I think we should just match KRunner's behavior here.
The user typing 'arc' then pressing Enter, and getting the file opened with wireshark is broken behaviour form the user's POV, that's the crux of the bug report in question.
That combobox uses KCompletion and not having the up/down arrow keys navigate through the possible completions in the popup menu, when the mode[1] is CompletionPopup or CompletionPopupAuto, would be broken behaviour too, and unexpected by the user; e.g. in Dolphin, typing a path, there's popup list with possible completions, the arrow keys navigate through that list.
KRunner is a different beast, it can search files, execute commands, invoke kcm modules, manage open windows... etc.
Besides, we are talking about a corner case, 9 out of 10 times you'll only get 1 match.
If the point is to fix just this corner case, maybe we can do so by putting exact matches at the top of the list.
I don't think that's possible; the proxy sort model doesn't offer a way to change the order of the shown results, IIUC, it just filters out/hides non matching items and displays what's left.
A sort model allows to define any sorting criteria you want (see QSortFilterProxyModel::lessThan), so this is technically possible: the criteria would say "if A is a match and B isn't, then A<B is true".
I'm not 100% sure that things jumping around while typing is a good idea though.
That's exactly what already happens though, as the list of search narrows itself while you type. KRunner does this too. I don't think it's a problem.
By "jumping around" I mean that even order can change, not just things being added/removed.
A would be before B, and then you type something, and B jumps before A.
Or do I misunderstand and this could never happen?
hmm... I was wrong then. It would complicate the code for a corner case; how many app names used today are substrings of other app names...
In this case it would have to be "if A is shorter than B"; also this is a tree model, we want to sort based on the leaf nodes (.desktop Name=), but not on parent nodes (the category names), I am not sure that is possible/straightforward with that item model.