Fix broken keyboard shortcut capturing for combos that include Shift #45
Conversation
|
Hi, |
|
Hi, thanks for checking this out. Maybe my pull request came a little early. On 16.08.2012, at 15:49, Nicolas Froment notifications@github.com wrote:
|
|
How is it doing? Ready for more testing? |
|
Hi, after you told me it doesn't work on Windows with a French keyboard, I tested my local most recent version on Xp/Virtual box, different keyboard settings etc. For me it worked IIRC. But it's a hacky answer to the shortcomings of Qt, so I'm not sure if this should even Jon Am 08.09.2012 um 11:13 schrieb Nicolas Froment notifications@github.com:
|
Example on a US keyboard layout, how it was before:
'Shift+,' would be captured as 'Shift+<',
'Shift+7' would be captured as 'Shift+&',
and such combinations did not work after configuring them,
because they are simply unpressable.
With the fix I'm proposing, 'Shift+,' is recognized as '<',
'Shift+8' as '*', and most importantly, they actually work as
shortcuts.
The fix feels a little bit hacky, because it relies on a Qt
implementation detail (the Qt::KeypadModifier flag), but there
seems to be no way in Qt to get the 'naked' keys (',' and '7'
in the examples above) when the user presses them with shift.
So I think this is still better than a broken shortcut
mechanism.
This is only tested on a MacBook Pro with OSX 10.8, so it
would be good if someone could test it on Windows/Linux,
preferably also with numpad keys.
Makes the code more readable and self-documenting.
Technically, it shouldn't be possible any more to have a broken shortcut list, since you can't create conflicts any more. But if you already have a broken shortcut list, it might be helpful to see all conflicts. Anyway, this is also a preparation to try a different use for the "replace" button. Rather than allowing multiple shortcuts for the same thing, it would be more useful to be able to resolve the conflict right from the dialog box, and actually that's how I would have understood the "Replace" button: it deletes the key sequence from the conflicting shortcut and sets it for the one I'm currently editing.
QLineEdit fields swallow certain keys on Mac, even if they are in read-only mode. Extended the fix for backspace to also handle delete.
Added a list of exceptions where the shift modifier must not be removed (keys like Enter, Backspace, Esc etc.). Now it's possible again to set Shift+Backspace, for example.
squash! Allow Shift combos for
Since Qt often adds the KeypadModifier flag to keys, e.g. the arrow keys, they get converted into something unreadable by QKeySequence::NativeText.
|
I too got bitten by this issue, > doesn't work as a Shortcut, as on a German Keyboard this is Shift-< (and recoded as Shift-> in MuseScore |
|
This PR may not be needed anymore, since the move to Qt5, does it? |
|
can't this PR get closed? |
This should fix that many Shift key combos were displayed wrong
in the capture dialog and didn't work afterwards.
See commit message for details.
Tested on MacBook Pro and 10.8 and Qt 4.8, Would be good to test this
also on Windows/Linux, also with extended keyboards (numpad keys).