114

hi,


my another feature request is simple (as always ) so please do the following:

- ALT+F2
- type something so that list is not empty
- and push DOWN ARROW key...

not working? yep - it should cause it is natural and intuitive


so that's all, please comment if you like it


cheers,
Wojtek

Totally agree. You can actually use Tab/Shift+Tab to navigate, but I think using arrow keys is much more intuitive.

Added "to krunner" to make the title more clear ([krunner] in the title was probably removed when converting to the new tag system).

after the first "TAB" you can use up/down arrows

finex wrote:after the first "TAB" you can use up/down arrows

Which is more than simple enough.

It would not be logical to browse results with DOWN key. The focus is still on the input box what is not same thing as results.

The logical thing now is that you need first press TAB to get focus to the results list and then you can use arrow keys.

The DOWN key would be logical only if you could not anymore browse history of the input box after you have typed something on it.

So it should be changed so that when you press DOWN/UP when not typed anything, you could browse the history. Tab does nothing.

When you start typing, the results gets filled down. Then you can not anymore use arrow keys to browse history but just the results view. Tab should then be completing if there is something suggested in the input box.

But all these were resolved long time ago. There was a great explenation from Aaron Seigon in his blog about KDE SC 4.3 time.

The problem still exist that KRunner is not like normal drop downlist. So you can not expect DOWN key to work as in Konqueror or in Dolphin.

Keys should be user-configurable. Me, I'd prefer using TAB to fill out the completion and Ctrl-n/Ctrl-p to move up and down (that way I don't have to move my hands away from the home row).

I'm totally against this - I'd have to update userbase page for Lancelot / KRunner comparison

Just joking, since up and down keys don't really have a useful job in KRunner (from my POV) this is a good idea.

The problem is that all Fri13's comments are all more than valid. So, implementing this would result in usage regressions.

Ivan, there should be _some_ key for browsing the results without moving focus. However, it doesn't have to be arrows of course (In any-case, these things should be configurable: brainstorm.php#idea88463_page1 )

This is a good idea , but, I would like to add something in this.

If we press up/down arrow then the selected application from list should be moved, and if we press left/right arrow then the cursor of the text box should be moved.

Marked as WONTFIX following the corresponding bugreports:
https://bugs.kde.org/show_bug.cgi?id=165179

@TheBlackCat, for curiosity, I followed the discussion in the bug, but i did not understood it, can you please explain?

The basic idea is that tab is always used for moving between different elements of the UI. The text field and the list of results are two different elements of the UI, therefore, to maintain consistency, tab is used to move between them.

TheBlackCat wrote:The basic idea is that tab is always used for moving between different elements of the UI. The text field and the list of results are two different elements of the UI, therefore, to maintain consistency, tab is used to move between them.

Thanks, it is clear to me now

Fri13 wrote:It would not be logical to browse results with DOWN key. The focus is still on the input box what is not same thing as results.

The logical thing now is that you need first press TAB to get focus to the results list and then you can use arrow keys.

That might be the "logical" thing for a developer who knows about the different Qt widgets involved on the technical level, but to a normal user, the search filed and results list together feel like ONE widget, similar to a drop-down list.

So it is very much logical to browse results with the DOWN key.

Having to press TAB in this situation is something that very few people would think of intuitively.

Fri13 wrote:The DOWN key would be logical only if you could not anymore browse history of the input box after you have typed something on it.

So it should be changed so that when you press DOWN/UP when not typed anything, you could browse the history. Tab does nothing.

When you start typing, the results gets filled down. Then you can not anymore use arrow keys to browse history but just the results view.

As I pointed out in a bug report about this several months ago, it would be entirely possible to seamlessly allow UP/DOWN-key navigation for BOTH the results list and the history list, for example by differentiating between the following four states:

1) [top-most entry in results list is selected - i.e., the initial state]:
--> UP key moves selection to bottom-most entry in history list
--> DOWN key moves selection to second-from-top in results list

2) [any other entry in results list is selected - i.e., the initial state]:
--> UP and DOWN keys move selection up and down within the results list

3) [bottom-most entry in history list is selected]:
--> DOWN key moves selection to second-from-top entry in history list
--> UP key moves selection to second-from-bottom in history list

4) [any other entry in results list is selected - i.e., the initial state]:
--> UP and DOWN keys move selection up and down within the history list

Of course, in ALL cases, typing text in the search field would still be possible as usual, and the LEFT/RIGHT keys would still move the text cursor to the left or right, without affecting the UP/DOWN key behaviour.

It's really not as complicated as it sounds - users playing with it without any explanation would understand how it works intuitively (as opposed to the current situation).

And that's just one of several possibilities. Another would be to let UP/DOWN always move selection in the results list, and CTRL+UP/CTRL+DOWN always move selection in history list (which is less important, therefore it gets the combination with added CTRL key).

Fri13 wrote:Tab should then be completing if there is something suggested in the input box.

Indeed, that is exactly what one would expect the tab key to do in a keyboard command interface like this.

Fri13 wrote:The problem still exist that KRunner is not like normal drop downlist. So you can not expect DOWN key to work as in Konqueror or in Dolphin.

Well, it LOOKS LIKE and FEELS LIKE some kind of drop-down list, so users certainly *can* and *will* expect it to behave like one.

No one says it has to be a *normal* drop downlist. It could be a special double-drop-down list like I described above.

There's no technical "problem" whatsoever preventing such a solution (or any other one, for that matter).

The only problem is that the krunner developers fail to recognize the need for some kind of solution in the first place, because they refuse to acknowledge how uninuitive the current arrow key and TAB behaviour in krunner is for normal users.