ngraham requested changes to this revision. ngraham added a comment. This revision now requires changes to proceed.
In D24951#554226 <https://phabricator.kde.org/D24951#554226>, @ahmadsamir wrote: > In D24951#554138 <https://phabricator.kde.org/D24951#554138>, @ngraham wrote: > > > 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. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24951 To: ahmadsamir, dfaure, ngraham Cc: ngraham, kde-frameworks-devel, LeGast00n, GB_2, michaelh, bruns
