FWIW, I had looked at that PR a while ago when I was trying to fix a related issue with tuplet creation. I don't think I saw that it had this bad effect. But if we do revisit this, we could maybe revisit the corresponding tuplet issue as well.
Well, if you (@lasconic) see a discussion about PRs on IRC as pressure...
Would be interesting to find and fix that strange side effect. Is it about something being wrong with shortcuts, and the . in texts wrongly being taken as a shortcut?
I am sorry that my PR introduced this bug.
Actually, it was just to cope with a minor problem, so we can happily go on without that change.
I investigated a little this shortcut clash. I think the problem was in unconditionally enabling the "pad-dot" and "pad-dot-dot" actions at lines 308-309 of keyb.cpp: getAction("pad-dot")->setEnabled(true); https://github.com/musescore/MuseScore/blob/2f8840d2fd/mscore/keyb.cpp#…
I introduced this to re-enable the action after it was disabled for a 128th note. But it seems that this enables the shortcut for the action also when it should not be used (for example text_edit mode).
I'm investigating into this too, and with @lasconics help I think I found something that seems to be working:
Adding into MuseScore::changeState() (and remove those 2 setEnable() in keyb.cpp):
@Jojo-Schmitz:
Thank you for the further investigation.
Have you checked that after the actions are disabled when highlighting a 128th note or rest (in normal and note_edit mode), they are enabled again when highlighting a note (or rest) with a different duration?
I remember I introduced those lines because the buttons were remaining disabled.
Guess the setEnabled() in keyb.cpp need to get moved into the default branch of the switch, rather than being set unconditionally.
Yes, that seems to work better, PR updated
Comments
Funny, just noticed the same thing, adding a . to a lyrics syllable.
Ctrl+. worked though
This issue appears there is two days, March 9.
With this Nightly, entering a point in a text box works (without Ctrl): 9726d8e
After seeing, the cause might be a side effect of a following Nigthly (the message mentionned is now displayed) ? 1af29ba
my immediate thought too...
fixed 2c626631fa
I reverted the PR https://github.com/musescore/MuseScore/pull/544 that I shouldn't have push in the first place. I should resist to the pressure a bit more :)
FWIW, I had looked at that PR a while ago when I was trying to fix a related issue with tuplet creation. I don't think I saw that it had this bad effect. But if we do revisit this, we could maybe revisit the corresponding tuplet issue as well.
It *is* fixed...
Well, if you (@lasconic) see a discussion about PRs on IRC as pressure...
Would be interesting to find and fix that strange side effect. Is it about something being wrong with shortcuts, and the . in texts wrongly being taken as a shortcut?
I am sorry that my PR introduced this bug.
Actually, it was just to cope with a minor problem, so we can happily go on without that change.
I investigated a little this shortcut clash. I think the problem was in unconditionally enabling the "pad-dot" and "pad-dot-dot" actions at lines 308-309 of keyb.cpp:
getAction("pad-dot")->setEnabled(true);https://github.com/musescore/MuseScore/blob/2f8840d2fd/mscore/keyb.cpp#…
I introduced this to re-enable the action after it was disabled for a 128th note. But it seems that this enables the shortcut for the action also when it should not be used (for example text_edit mode).
I'm investigating into this too, and with @lasconics help I think I found something that seems to be working:
Adding into MuseScore::changeState() (and remove those 2 setEnable() in keyb.cpp):
else if (s->key() == "pad-dot" || s->key() == "pad-dot-dot")
a->setEnabled(!(val & STATE_ALLTEXTUAL_EDIT));
@Jojo-Schmitz:
Thank you for the further investigation.
Have you checked that after the actions are disabled when highlighting a 128th note or rest (in normal and note_edit mode), they are enabled again when highlighting a note (or rest) with a different duration?
I remember I introduced those lines because the buttons were remaining disabled.
Hmm, damn...
Have a look at https://github.com/musescore/MuseScore/pull/1873
Guess the setEnabled() in keyb.cpp need to get moved into the default branch of the switch, rather than being set unconditionally.
Yes, that seems to work better, PR updated
Automatically closed -- issue fixed for 2 weeks with no activity.