Users used to emacs/bash style of navigation and editing might appreciate a basic support for it in Kickoff, especially Ctrl+n/p for next/previous entry.
Details
Details
- Reviewers
davidedmundson
Check if the keys work as expected, i.e.:
Ctrl+n - cursor key down, highlight next item in the list
Ctrl+p - cursor key up, highlight previous item in the list
Ctrl+h - backspace, removes last character in the search field
Ctrl+e - end key, move cursor to the end of the search field text
Ctrl+f - cursor key right, move cursor one character right in the search field
Ctrl+b - cursor key left, move cursor one character left in the search field
Ctrl+[ - esc, here the code in the patch copies Kickoff's handling of Esc key, that seems to always result in closing Kickoff despite an if condition
Diff Detail
Diff Detail
- Repository
- R119 Plasma Desktop
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
KDE has a concept of "standard shortcuts". Instead of duplicating this same code everywhere with various combinations for people doing all sorts of crazy bindings, which is eternal we should be just looking into fixing this (if it's indeed broken) or expanding upon it if needed.
Comment Actions
Does the mechanism of standard shortcuts really apply here? Just below the code I added is the code explicitly handling keys like Qt.Key_Up, Qt.Key_Down, Qt.Key_Tab, etc. Seems like it's all hardcoded. Adding those keybinding to standard shortcuts has no effect.
Anyway, would you be willing to accept just a special handling for ctrl+n/p if this patch is too much?
Comment Actions
Does the mechanism of standard shortcuts really apply here?
It's not implementing it yet, but that's the entire point.
The bigger problem is someone added some vim shortcuts to krunner a year ago: (plasma-workspace a58e48707601d627781c6681389e4abe0f6e8899) in hindsight I shouldn't have accepted it.
This is showing there's a bigger problem that needs to be addressed at the root. We can't be inconsistent with secondary shortcuts within our own code. Sorry.
In terms of actions this means:
- exposing KStandardAction::rotateUp/rotateDown somewhere generic
- porting from KeyEvent to Shortcuts inside the QML
Comment Actions
In terms of actions this means:
- exposing KStandardAction::rotateUp/rotateDown somewhere generic
- porting from KeyEvent to Shortcuts inside the QML
Thanks for the explanation. This sounds like a time-consuming project for someone unfamiliar with that stuff. I'll stick with a locally patched Kickoff for now.