If I pick a command, then pick the entry field, then try to assign alt-a, alt-e, alt-i, or alt-d – then the controls in the dialog itself, with those shortcuts, are clicked.
The desired key IS also entered in the field, and so CAN be assigned – except for alt-e (the “clear” action clears the field, though I see “Alt-E” blink in it), and alt-d has the very bad side effect of restoring all defaults! Alt-i pops up a nuisance dialog I don’t want.
I think this dialog should have no keyboard shortcuts of its own, to avoid this confusion.
No show stopper of course, I just chose different shortcuts.
Oh, and by the way, it’s also impossible to assign Tab to anything.
Without the use of TAB (or ALT keys on Windows and Linux) the blind user or user who cannot use any type of mouse has no way to navigate.
On Linux it seems the worst of all worlds prevails in that when focus is in the text box, shortcuts using ALT like ALT + I operate the buttons without adding the shortcut, but once you are in that box there is no way out without using the mouse. TAB, ESC and RETURN are all accepted as shortcuts.
We could disallow ALT to operate the buttons in the specific case when focus is in the box, meaning that blind users must TAB out of the box to the “Set” button to set the shortcut. Or (as in 1.2) we could remove the access keys that currently operate with the “Clear”, “Import…” and “Defaults” button so that any button must be navigated to by using TAB.
Note that ALT + I and ALT + E are in use by default so could not be added, and ALT + A does add the shortcut as far as I can see.
I’ll ask David Bailes what he thinks. As a workaround, you can import an XML file that has the ALT shortcuts you want to use (this does not work in 2.0.3 release but is fixed in 2.0.4 alpha), or paste in the ALT shortcut you want.