fixed #12791: Num pad not responding for duration selection

[Eism]

Resolves: #12791
Resolves: #12956
Resolves: #15204
Resolves: #14505

[Jojo-Schmitz]

Could you add NumPad + Enter as an additional shortcut for System Break?
Would fix #12956

And NumPad + dot for dotted duration?
And maybe NumPad ++/- for sharp/flat?

Maybe NumPad + / and NumPad + * for half and double duration

[Eism]

@Jojo-Schmitz thanks, makes sense for
And NumPad + dot for dotted duration?
And maybe NumPad ++/- for sharp/flat?
Maybe NumPad + /

Did not find a sequence *

[Jojo-Schmitz]

Double/half duration, W and Q. Also with Shift

[Eism]

Why we should use NumPad+/ and NumPad+* for half and double duration?

[Jojo-Schmitz]

Why we should use NumPad+/ and NumPad+* for half and double duration?

Because those are otherwise unused? I'm open for better suggestions though. Not using them at all seems a waste.
Maybe acciaccatura/appoggiatura? Might even be better.

OTH instead of flat/sharp I'd rather have NumPad + for Tie, maybe Numpad + - for Slur? Would allow easy note entry with one hand on Numpad and the other on mouse, excatly my favourite workflow

[Eism]

For other changes please create a separate issue

[Jojo-Schmitz]

Tested: durations (1-9) work, /, +, - and Enter works, but . (resp. , in my case) does not,
Windows 11, German QWERTZ keyboard, German language settings

Changing to

    <SC>
        <key>pad-dot</key>
        <seq>.</seq>
        <seq>Num+.</seq>
        <seq>Num+,</seq>
    </SC>

makes 'dot' work for me. Needed for all of continental Europe as far as I can tell

NumPad+0 doesn't work for Rest

    <SC>
        <key>rest</key>
        <seq>0</seq>
        <seq>Num+0</seq>
    </SC>

fixes that. Both are vital shortcuts that did work in MU3 out of the box

So we're almost there ;-)

[Jojo-Schmitz]

Great! Now Mac and AZERTY users would need to test I guess

[Jojo-Schmitz]

Darn, that dreaded spurious unit test failure again...

[Flying-Roger]

See my recent post on #15204:

I noticed that there is a discrepancy between the way detects the numeric keypad while editing a score with respect to what it does while defining shortcuts:

while defining a shortcut, pressing 0 on the alphanumerical keyboard or pressing 0 on the numeric keypad has exactly the same effect: "0" is recorded for the shortcut.
while editing a score, pressing 0 on the alphanumerical keyboard does what is defined as "0" in the shortcut xml file, while pressing 0 on the numeric keypath does is not detected as "0", but as "Num+0", thereby requiring a specific definition in the shortcut xml file.
This is a bug : the consequence is that it is impossible to define a shortcut on the numerical keypad via the shortcut definition menu. The workaround is to export the shortcuts in xml, edit the xml to add the Num+x definitions and reimport the xml file.
I see that this topic is noted as "fixed", but I recommend to make sure that the root cause reported here above is also fixed.