Bug 211791 - shortcut dialog is very cumbersome to use with keyboard only
Summary: shortcut dialog is very cumbersome to use with keyboard only
Status: CONFIRMED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: shortcuts (show other bugs)
Version: 4.3
Platform: Debian testing Unspecified
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
: 178998 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-10-25 16:47 UTC by Milian Wolff
Modified: 2017-07-15 19:46 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Milian Wolff 2009-10-25 16:47:24 UTC
Version:            (using KDE 4.3.2)
Installed from:    Debian testing/unstable Packages

Imo a very severe usability problem:

The short cut dialog, e.g. accessible via krunner -> global shortcuts, is _very_ cumbersome and unintuitive to use with _keyboard only_. I mean this is a dialog that is essential when the mouse doesn't work / is not available (like right now, battery dead...).

To reproduce, try to define a shortcut for e.g. "move to next desktop".

Currently you have to do:
Alt + F2 -> global shortcuts -> select correct kcm runner (this is really good, nothing has to change here!)

1) Now you'll spot the first issue: Keyboard focus is on the "defaults" key... instead it should be on the "kde component" dropdown, so I can easily select "Kwin". Instead, right now I have to use tab repetitively to focus the dropdown and can finally select kwin.

2) Now let's search for "next desktop", when looking at the dialog you'd assume that, when the dropdown is focused, you'd have to press tab twice. Instead, first tab focuses the "File" button, but afterwards it focuses the shortcut list, instead of the search lineedit. => bad

3) Once you searched for "next desktop", focus the shortcut list. Up-Down navigation with arrow bars is fine, but pressing left/right moves to focus into oblivion, dunno where exactly. Unintuitive

4) To expand a shortcut item, you have to press "space". When you hit "enter"/"return" (as I did the first time(s)...) you "OK" the dialog and it closes => all "work" is lost. _Very bad_!

5) Once you expanded an item, you cannot focus it's items with tab/arrows, instead you have to use accelerators. Also very unintuitive.

6) When you focus the "custom" label by hitting it's accelerator (u in my case), the widget that waits for a new shortcut should get activated imo. Instead, you have to: a) focus "custom" by hitting "alt + u", b) focus the shortcut widget by hitting "alt + n" (note: the last accelerator changes depending on the current associated shortcut, not very convenient imo).

7) Once you expanded an item, you cannot close it again by hitting space again.

8) Once you expanded an item, you cannot expand another item by selecting it and hitting space again.


I hope you see that this is in dire need of some usability help!
Comment 1 Christoph Feck 2009-12-02 09:27:55 UTC
*** Bug 178998 has been marked as a duplicate of this bug. ***
Comment 2 Michael Jansen 2009-12-07 23:03:32 UTC
*** Bug 182873 has been marked as a duplicate of this bug. ***
Comment 3 Christoph Lange 2010-07-30 22:49:05 UTC
(In reply to comment #2)
> *** Bug 182873 has been marked as a duplicate of this bug. ***
Just noticed this duplicate declaration.  Will a fix of this bug also fix bug 182873?  I'm not familiar with the libraries behind keyboard shortcuts, but to me the user interface for assigning a window shortcut seems quite different from the shortcut dialog, so I'm not sure whether this is really the same bug.  Is it?
Comment 4 Thiago Jung Bauermann 2012-05-17 18:37:07 UTC
Still an issue in KDE 4.8.3.
Comment 5 andydecleyre 2017-07-15 19:46:34 UTC
Still very much an issue with plasma-desktop 5.10.3.