Selection after "Split measure before selected note/rest"
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
After performing of said "Split measure before..." function, there seems to be no 'default' selection afterwards. This makes keyboard traversal a burden in that the user has to select where next to be working. For example, if the user enters into Note Entry after splitting the measure, some guess-work is done by Musescore rather than the suggestion: let the selection be at the beginning of the newly formed measure after splitting, whether that be a note or a rest, so that left/right arrows act from that position which would also allow for Note Entry to enter upon the first beat of the newly formed measure right after splitting, rather than, for example, the previous system as it seems to do by default.
Comments
As of 3.3, even in the cases where selection is lost, Alt+left/right will resume navigation where you left off.
Meanwhile, though, it makes sense to select something here.
In reply to As of 3.3, even in the cases… by Marc Sabatella
Thanks for the tip
In reply to Thanks for the tip by worldwideweary
Hey, P.S.: The same behavior occurs in generally deleting a measure, like when using the "Remove Selection Range". Selection is lost afterwards in 3.2.3. Haven't tested in 3.3 whether the Alt-direction motion will resume here, but based on Marc's statement, it should. Still, it seems logical to have the measure--in the case of splitting/joining/deleting--that becomes whichever measure number the current selection was previously on to become the current selection at first beat, or some similar default beat selection, since there's always a selection either as a note/rest or as a range selection prior to performing: [splitting/joining/remove selection range].
It does indeed resume in 3.3 after measure deletion. In general, we should pretty much always be able to resume navigation after deleting things or doing anything else that loses the selection, because we are tracking the time position and staff number of the last navigation, not specific elements.