@BetterRed
Regarding the bug in Preferences KeyShortcuts that Tab focus will not properly move to the Assign button or the Remove Button ...
I have looked more closely at this and it appears to be a bug in Qt's previousInFocusChain and nextInFocusChain not including buttons that are independently enabled and disabled as this chain appears to be built once and static at the QWidgets creation (which makes no sense to me).
As it stands now, using Qt::KeyBackspace when in the shortcut field (ie. the delete key on my Mac) will properly invoke the Remove button if enabled.
The same things should work on Windows.
For the Assign button, there is no possible single key to launch it given you are in the shortcut creation field that would not be a valid possible field value.
Tab should handle this case but it does not (the nextInFocusChain Qt bug).
So unless we can figure out a single key that could be used to launch Assign (to work around this) that is not useable in assigning a shortcut we are pretty much out of luck working around this bug and will have to wait for a fix from Qt.
Sorry.
Update
--------
To workaround this Qt bug - I tried using setTabOrder but that was ignored.
Finally, I did find a way to force inject the Assign and Remove buttons into the focus chain after the Shortcut field (given they are properly enabled) with this bug workaround:
Code:
diff --git a/src/Dialogs/PreferenceWidgets/KeyboardShortcutsWidget.cpp b/src/Dialogs/PreferenceWidgets/KeyboardShortcutsWidget.cpp
index 8455ada0f..b8ec36566 100644
--- a/src/Dialogs/PreferenceWidgets/KeyboardShortcutsWidget.cpp
+++ b/src/Dialogs/PreferenceWidgets/KeyboardShortcutsWidget.cpp
@@ -293,7 +293,13 @@ void KeyboardShortcutsWidget::handleKeyEvent(QKeyEvent *event)
if (nextKey == Qt::Key_Tab || nextKey == Qt::Key_Backtab) {
QWidget * upnext = nullptr;
if (nextKey == Qt::Key_Tab) {
- upnext = nextInFocusChain();
+ if (ui.assignButton->isEnabled()) {
+ upnext = ui.assignButton;
+ } else if (ui.removeButton->isEnabled()) {
+ upnext = ui.removeButton;
+ } else {
+ upnext = nextInFocusChain();
+ }
} else {
upnext = previousInFocusChain();
}
This "workaround" has been committed to master and will be available in the next release (which may be quite some time from now).