Escape loses focus even when it shouldn't
Reported version
3.4
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
by design
Regression
No
Workaround
No
Project
When a note is focused in normal mode and the selection is extended to cover several notes, e.g. in order to add hairpins, articulations, etc., Escape makes focus lost altogether. This MAY be desirable in some contexts (although I can't figure out when that would be), but in most cases, one would want to preserve focus on the single note that was focussed before the extension.
The position is clearly stored, since entering and exiting note-input mode keeps focus on the correct note.
Should there be an additional "Escape" step in this case, similar to the sequence of Escape's one goes through when editing a hairpin?
Comments
It's by design, and absolutely expected according to standard use models of selection, that Esc clears the selection, immediately, no need to hit it twice. However, we do indeed keep track of where the "cursor" (there really isn't such a thing, but we just treat a single selected element as if it were a cursor) even when lost. Simply use Shift+L to restore it, or use Alt+Left/Right to restore it and resume navigating.
Well, I would say that it's then both inconsistent behaviour and counter-intuitive. There are cases where Esc does NOT leave focus altogether, but instead goes up to the next level of activity. For example, when entering a hairpin, focus is on the right anchor, and Esc moves focus up to the hairpin itself. That, to me is expected behaviour (and consistent with a general model). (BTW: when in Normal mode, Esc on the hairpin anchor leaves focus altogehter).
What I would expect is that when I move along the score and want to add a series of staccatos, I should be able to do so and continue along the same track - there shouldn't be any difference between adding something to one single note and to a group of notes, like it is now.
The shortcuts you mention seem interesting (although undocumented, afaict), but they don't do the same as the suggestion.
When editing a hairpin, you are in edit mode, you don't have a range selection to possibly lose. Esc indeed has the effect of existing edit mode and return you to normal mode.
I'm not aware of any situations where, with focus on the score itself in normal mode, Esc does not clear the selection. If you know of any. please let us know, that would be a bug.
Certainly if the focus is not in the score, then esc doesn't lose the selection, it just returns it to the score. And if the score is not in normal mode, then Esc simply returns to normal mode (eg, from note input or edit mode).
So I'm having trouble understanding the situation you mean you expect that somehow pressing Esc in normal mode should not clear the selection. What else should it do instead? There should be no other reason to pressing Esc in normal mode except to clear the selection, that is its sole purpose in that mode. And I'm not understanding the difference you mean between adding a staccato to a single note or multiple note. I don't see any difference at all. With either one note or a range selection, Shift+S applies staccato. and then you can continue navigating or selecting with no reason to press Esc.
Alt+Left/Right are documented, they are an important part of the accessibility features, so they are heavily featured on that page. They are also listed in that navigation section of the keyboard shortcuts page. Shift+L was only just added at 3.3 (I think), not sure if it's made it into the Handbook yet other than the accessibility page.
I was not aware of the Shift-L command - it is a welcome addition. But it then invites the question the other way around, which is really my main issue here: When is it that you would NOT want focus somewhere? Or rather: since MS internally has focus somewhere, when would you NOT want to know where that is, and to be able to interact with it?
Here are some points that I noted down while doing some editing, involving articulations, dynamics, texts, etc., where I perceive an inconsistency in the way focus is handled:
Enter multi-note hairpin. Esc+esc -> focus is lost
Enter multi-note articulations: arrow moves to next note, as you point out (i.e., focus is active and visible)
Same action - different behaviour.
Not identical cases, but related, in that visible focus is preserved after destructive events:
- Select dynamic, staff text, etc., delete it -> visible focus goes back to the note to which it was attached, even if that note wasn't selected previously.
- Select lyric syllable to edit; esc: edit mode is left, but visible focus is still on the syllable. Another Esc loses focus altogether.
In sum: I don't necessarily want Esc to work in a different way than it does - it seems to be consistent - but ultimately to have a smooth and intuitive workflow. The way I visualize what I do in a score involves separate levels, where I would e.g. (1) be on a note; (2) enter a hairpin, (3) edit its endpoints; press Esc to get back to the previous level (2), and from there get back to level (1) again. Esc now does that from (3) to (2), but to get back to (1) again, I would have to press Shift-L. Why not let that happen automatically?
PS: The Alt-arrows: interesting, but seems to move to next element including all elements, or?
The point of Alt+Left/Right is to navigate through all elements, yes - as I said, a crucial part of the accessibility features.
It might be possible to redesign things so that losing selection was never possible,. There are only a few things I can think of offhand that really require starting with nothing selected - Shift+click to create an instant range selection being the main one. Many people are probably accustomed to to running commands with no selection when it is actually defined to do the same as all selected, they could be retrained I guess. Mostly, it's just kind of standard UI design for programs involving placing elements on a canvas to be able to have nothing selected. It's different from a text editor in that way. And yet, it's also similar in other ways. Worth discussing further in the forum where more people will see and be able to take part. The real issue here is, how could the notion of a "current location" (cursor) be maintained that is potentially different from the idea of a "selection".
Having focus return to an element after deleting something is an important feature, yes, because we don't lose focus unless you specifically issue the one and only command whose sole purpose is to clear the selection. In that case, we absolutely do want this, there's no point in a "clear selection" command that in fact does not.
I'm not understanding you're bullet point list, I don't know what a "single note hairpin" is but a hairpin on one note correctly gets unselected when I press Esc. If you do start a discussion on the forum, feel free to elaborate there.
Will take it there.