MuseScore
MuseScore copied to clipboard
musescore
Restore previous selection on arrow keys when nothing in the score is selected
As discussed in #23901 (although the issue is about something slightly different), I find it nonsensical and at times annoying that when accidentally pressing an arrow key when nothing is selected, the selection jumps to the first bar.
Before my changes, the behavior for empty selection was as follows:
- On Up/Down press, the first vertical bar line segment left of bar 1 of the first instrument is selected.
- On Left/Right press, the first note or rest in bar 1 of the first instrument is selected.
I argue that arrow keys should simply be ignored when nothing in the score is selected, and that is what this PR does.
- [x] I signed the CLA
- [x] The title of the PR describes the problem it addresses
- [x] Each commit's message describes its purpose and effects, and references the issue it resolves
- [x] If changes are extensive, there is a sequence of easily reviewable commits
- [x] The code in the PR follows the coding rules
- [x] There are no unnecessary changes
- [x] The code compiles and runs on my machine, preferably after each commit individually
- [x] I created a unit test or vtest to verify the changes I made (if applicable)
I'll review properly tomorrow, but I'm happy for the arrow keys to do nothing as long as Alt+arrow still selects something. Blind users need a way to select something without clicking.
I'm happy for the arrow keys to do nothing as long as Alt+arrow still selects something.
That is the case, although of course this does not select a measure like only the arrow keys used to.
I actually just discovered a bug while checking this: Independently of my changes, if you open a score, change to continuous view (horizontal), press Alt+Right and then Right, MuseScore crashes. I'm gonna report it separately (edit: reported #24234).
I'm happy with the implementation here, assuming we want to ignore the arrow keys.
But rather than ignoring them, I think it would be better keep track of the user's position when they press Esc, and pick up again from that position if the user subsequently presses an arrow key.
For example, let's say you have a note selected in the middle of a very long score. If you press Esc this note is deselected, so there's no longer any kind of selection. But if you subsequently press Alt+Right, navigation continues from where you left off, not from the beginning of the score.
I think the Right arrow key alone (i.e. without Alt) should exhibit the same behaviour, though navigation should continue from the exact same element as before rather than from the one next to it or the one at beginning of the score.
@svetter, would the behaviour described be enough to bypass the problem you were having with unintentional key presses causing you to lose your place?
Personally, I'd rather see the cursor keys work to move the canvas when nothing is selected, but I'm happy with anything other than cursor keys acting like Home.
@shoogle Returning to the last selected element is a good idea, I should have thought of that in the first place. I'd prefer that to moving the score but of course I can only speak for myself.
Should I go ahead and try to implement this? Should I amend this PR or just start a new one?
@svetter, yes please!
@MarcSabatella, moving the canvas (or rather the view) is also acceptable. Perhaps we should implement that as an option in Preferences. It could also apply to Home, End, Page Up, Page Down, etc. When there's no selection, they would just scroll the view.
But an option in Preferences needs input from a designer. For now, I suggest @svetter just implements reselecting the last selected element.
This remark may be superfluous, but watch out that the implementation takes into account that the last selected element may be deleted without touching the score view, so this shouldn't cause crashes or unexpected behaviour. For example, if the last selected element is on some staff but that staff is deleted using the instruments panel, that element will have disappeared at the moment that the user focuses the score view again and tries to use the arrow keys.
In most cases, removed elements will not be deleted in memory because they continue to live in the Undo stack (but still they shouldn't be referenced anymore at that point); but Brackets are known as dangerous elements because they are deleted and recreated during every re-layout.
Home, End, PgUp, and PgDn already scroll the canvas. whether anything is selected or not. But cursor keys would be nice to have in addition, for finer movements.
@cbjeukendrup - concerns about that are in part why Shift+L doesn't actually try to remember the element itself, just the input position.
Thanks. My work on this is indeed stalled, but not forgotten about - tbh I was a bit intimidated by the complexity added by @cbjeukendrup's remarks, and had little time due to a job change. I might pick this up again soon.
Alright, I looked into this for about four hours now and in the end I got absolutely nowhere. The best I can offer here is to just use the code which would be called on Alt+
The behaviour as it is now is somewhat inconsistent, because so is the current behavior of the Alt+ shortcuts. Going the the left of the previous (now cleared) selection will often go to the right instead, going right might skip an element. But it does select something in the vicinity of what was previously selected.
I'd argue that this is much better than the current behaviour of going to the start of the score. If this isn't good enough, someone who knows the selection code needs to look at this because I'm beat. Also I can't test on the newest master since it doesn't build for me.
@svetter, thanks for your investigation! I've added an extra commit that should keep the selection a bit closer to where it was before. Let me know if you're happy with this change.
I rebased the branch, so if you want to checkout the code locally you'll have to drop your local changes:
git checkout move-no-sel
git fetch origin move-no-sel
git reset --hard origin/move-no-sel
@shoogle Thanks. I'm sure it's good but as I said, I can't test it now because some change in the last two months apparently broke my local build process (it works fine on older commits) and I haven't figured out how to fix it yet.
But the only thing I wanted in the first place is not have the canvas yanked away from under my hands when I misclick and press an arrow button when nothing is selected. That is the case so if you're fine with this, you can merge the PR.
@shoogle Sorry about the new review request, I misclicked (ironically) but it's all good from my side