Automatically set initial selection when creating or opening a score
I suggest that MuseScore automatically set an initial selection whenever a score is created or opened:
-
When the user creates or opens a score, MuseScore performs the equivalent of the “rewind” command, causing the first element in the first voice on the first staff to be selected.
-
When MuseScore continues the last session on startup (if this option is enabled by the user), it restores whatever the last selection was for each score in the previous session. Note that the view (page(s) in view, pan position, zoom level) is currently already being restored for each score when continuing the last session.
I think doing this would help workflow and accessibility, because it would make keyboard navigation both immediately available and more discoverable for new users. It would also make editing facilities (Inspector, Note Input toolbar, etc.) immediately usable.
I volunteer to implement this myself.
Comments
I approve of the idea for sure! But I'd make a couple of small amendments/additions.
The rewind operation is actually good, because it doesn't select the first element, but rather the first note or rest. It's an important distinction, because Left and Right don't do anything unless a note or rest is selected. So making sure the first selection is a note or rest is definitely important.
On top of that, it would be good if Left and Right both did what Alt+Left and Alt+Right do, which use Selection::currentCR() to re-establish the last selected note or rest if there is no selection. I didn't do this for left/right when I implemented it for Alt+Left/Right I guess because I was afriad of changing existing behavior, can't really think of a better excuse.
Then there is #297426: The playback cursor is not repositioned when selecting items other than notes, rests or measures, which relates to the same basic experience.
Implementing your idea for re-establishing the selection is rather more complicated - what if, for example, it's a list selection consisting of a bunch of random elements? Or a range selection with certain element types excluded by filter? Tricky to even decide how to write that info to the session file. But at least remembering the "currentCR" (see above) and restoring the selection to that would be pretty simple.
In reply to I approve of the idea for… by Marc Sabatella
Thanks for your reply and your support.
Yes, I did actually mean that MuseScore should select the first note or rest; I just wasn't being precise.
Regarding the second part of my suggestion: I don't personally care too much about it (since I don't use the “continue last session” feature myself), but I included it for the sake of completeness and consistency. I will say that I imagine it would be nice to be able to pick up exactly where one left off, down to the selection — especially if it's a complex selection. This is especially true if MuseScore is recovering a crashed session, which can happen even if the user has “continue last session” disabled. If, as you fear, it ends up being too challenging to implement quickly, I have no problem with going ahead with just the first part and then maybe filing a separate issue for the second part.
I didn't know that you had implemented that auto-select feature for
Alt+LeftandAlt+Right(previous/next element). That's great, and I agree that it would be good to have it forLeftandRight(go to previous/next chord) too. I'd go further and also implement it forCtrl+LeftandCtrl+Right(go to previous/next measure). All of this should probably be filed under a separate issue, though.In reply to Thanks for your reply and… by Spire42
Separate issues for the suggestions are good, but it's also OK to have a single PR that fixes multiple issues. Where possible, I like to put the separate fixes in separate commits.
I'd definitely keep the session stuff completely separate, though. It opens a whole can of worms involving deciding on a format for writing the session file, no reason that should derail the rest of the work.