Why is edit mode required for arrow keys to "do" something

• May 1, 2016 - 20:51

Single click a sharp sign; it is selected but not in edit mode.
Using the keyboard arrows doesn't do anything.
Double click it (or ctrl-E): now you are in edit mode (no visual feedback however except the status bar, well known issues 108966 and 45491, but this is off topic).
Now using the keyboard arrows moves it.

My question is: why do you absolutely need to be in edit mode to be able to move it?
Once the element is selected, the keyboard arrows doesn't do anything anyway, so why could they not already move the element?

The question is even stronger for elements having several handles once in edit mode such as the bracket of a triplet: when the bracket is selected, using the arrow keys could move it (all handles by the same space), and once in edit mode, arrow keys would move handles individually as today.

?


Comments

In my opinion it would be way to easy to accidentally make all sorts of small manual adjustments unintentionally if we didn't require edit mode. In fact, I think it is a msitake that we allow it for rests (up & down), and the only reason I'm OK with it for text is that double click is needed to actually edit the text. Making manual adjustments is supposed to be an uncommon operation not to be undertaken lightly.

Consistency.
Single click a note and use the arrow keys, now double click it and use the arrow keys: different behavoir, and some where single click doesn't have a counter part for things like text or accidental.

In reply to by Jojo-Schmitz

BTW, some users also find it bothersome that a single click is enough to enable up.down arrows to change pitch - they expect up/down to simply navigate, just as left/right do. Most likely at some point we'll implement an alternate set of shorcuts you can select in order to get that behavior - up/down/left/right to navigate, some other keystroke needed to actually change pitch. I'm too accustomed to how it is now to wna tthis myself, but people using MuseScore primarily to browse scores rather than create/edit them find the current behavior frustrating.

In reply to by frfancha

'what about the advantage that you could then easily move all handles by the same amount of space'

=> ok forget it, normally there is a special handle meaning "full object" allowing to do that.

It is missing for the bracket of triplet which I used to make tests however.

In reply to by frfancha

Thinking one night about it...

The principles you mention are (in no specific order):
[A] - Ease of use
[B] - Consistency
[C] - Priority to navigate for arrow keys

Today, to move an entire object by keyboard, you have to "guess":
Is it a chord name? Ok single click.
Is it a hairpin? Double click, find the main handle, single click it.
Is it a fingering? Single click.
Is it the '3' of a triplet? Double click , find the main handle, single click it.
Is it a lyric? Single click.

=> That's not [A] easy to use and not [B] consistent.

Single click, selecting the object, should always be enough.
But then how to ensure [C], priority to navigate?

=> I propose this:

After single click:
- arrow keys ALWAYS navigate (never move the selected object)
- [Alt] + arrow keys ALWAYS move the object

That would be easy to use, consistent, and giving priority to navigation by arrow keys.

?

In reply to by frfancha

On the surface that sounds good, although I would say it's not really as complicated currently as you make it sound. Basically, text works on single click because double click has a different meaning that everyone knows and expects. Everything else requires double click. True, some elements have handles and others don't, but you don't need to guess anything - the handles either appear or they don't, so you get the feedback you need. Although blind users don't, which is worth considering. I actually think handles should *always* appear, even for elements like notes or articulations that would have only a single handle.

Arrow keys to navigate even when selecting things other than notes has a lot of appeal for several reasons, though. One is, again, accessibiltiy for blind users, but another is providing an easy way to move selection between notes and symbols. A bit easier said than done, but something I am definitely considering.

We'd still need to consider the case of up/down and whether we really want to sacrifice ease of use (these keys are very convenient for adding accidentals or for transposing) for the sake of consistency. Right now, my vote is that these stay as is for now.

In reply to by frfancha

Since we're considering significant changes for 3.0 development, you picked a good time to bring this up. I think you named the three important points accurately, and your proposal takes care of them in a largely reasonable manner.

As I understand it, this would basically do away with edit mode except for elements that can actually be edited in some way (such as text or spanners). Meanwhile those same "editable" types of elements would also be movable, like those without an edit mode (such as noteheads and articulations), in a way that lines, for instance, currently are not.

I would very strongly urge that this not change the ability to alter notes with the up and down arrow keys, though. This is an important aspect of note entry, whether to add accidentals or to correct wrong notes, and new users in particular would be very hard hit finding seemingly no way to change notes. [Alt]+arrow keys would allow for moving the notehead the way edit mode currently does, without actually changing the note.

Also, don't forget that [Ctrl]+[Arrow] (or [Cmd]+[Arrow] on Mac) should be the same as [Alt], except moving the object in increments of 1sp instead of 0.1sp.

In reply to by Isaac Weiss

I wouldn't have interpreted the proposal as "doing away with edit mode", just adding an additional shortcut for moving elements. I would assume we'd keep the existing edit mode as well.

Also, currentl Alt+Left/Right is not defined, but Alt_Up/Down is - it moves the selection up and down through the notes of a chord, voices, or staves. And I think this is a far more useful command than nudging individual elements, so I'd propose it stay the way it is, and the new nudge command would be something else, except we're pretty much out of modifiers, so we might need to take a step back and ret-think some things if we are to do do this. Personally, I'm not so sure we need a single-click nudge command. I'd be fine with Enter to switch to edit mode followed by left/right/up/down where entering edit mode in this way would be guaranteed to select the necessary handle for nudging.

I think any proposal along these lines should also consider the select behavior and maybe think through consistency of shortcuts. I have observed that Ctrl+click could be enahcned - without sacrificing current behavior - to have it cycle through multiple overlapping elements rather than just adding/remove a single element. Unfortunately I can't find the post where I proposed this, and discussed other aspects of selection (in response to a question / proposal by someone else, I think). But also, I recently proposed Alt+click be a special "select entire chord" command. Not sure all these proposals really will seem consistent if we do them all, but I'm not sure they *won't* either. Anyhow, something else we should think about. If we're going to make big changes, we should take the time to look at the big picture and do what's right.

In reply to by Isaac Weiss

Thanks for your answers, I really appreciate it.
It shows that thinking about MuseScore in the night instead of sleeping is worth it (do not repeat that to my boss or, even worse, my wife ;-) ).

I hear the need to keep simple direct way to add/remove half tone to note (currently arrows up/down), change octave (currently ctrl + arrows up/down) and move selection between note of the same chord (currently alt+arrows up/down).

What about this:

-In note entry mode:
one would keep the existing shortcuts. Entering notes (including quick changes of half tone/octave) would stay exactly as it is today.

-Not in note entry mode with a selected element:
arrows and Alt + arrows would be changed as proposed.
That means that to change the selected note in a chord (Marc's remark) one would use the arrows up/down without the alt.
And to change half tone then?
=> One would add the ability to press and keep pressed the 'N' key (the letter N as note entry mode), and while this key is pressed all other keys would behave as in note entry mode!
Simple and logic.
I agree, it means that to add or remove a half tone, when not in Note entry mode, you would have to press N+Arrow instead of only arrow as today.
But it has also advantages: all "keys" from note entry mode would be available without fully entering note entry mode.
Example: The score is entered, and you are busy making small adaptations (not in note entry mode, you are busy to select elements at various places of your score). You have a bass C and you want to change it to E.
Currently you select the C, press E. Ok, but ... you are back in note entry mode.
But as you are busy clicking on different elements to make adaptations, the first thing you want to do after that is to quit note entry mode.
With the proposed change, it wouldn't be necessary anymore:
If you want to change the C in E and stay out of note entry mode, just select the C, press N+E and that's it.
This is true for any 'note entry mode' command that you would want to use.

?

In reply to by frfancha

No, sorry, I don't like making up/down behave differently in note input mode versus not. And using "N" as a modifier, while it might be technically possible, would be almost completely undiscoverable by the average user; I'd rather not see *any* behavior tied to non-standard keyboard usage. I do like the idea of having increased access to note input mode commands while not in note input mode, but I don't think that's the way to do it. And in any case, changing pitch needs to stay as easy as it is today. That is far more important than any tweaks we might make to very rare operations like manual adjustments to position of individual notes.

In reply to by Marc Sabatella

> I don't like making up/down behave differently in note input mode versus not

-Lot of things behaves differently in note input mode versus not. This is the purpose of note input mode.
-By implementing both proposals, in total you would have less different ways that arrow keys behave, not more (as out of note input mode they would always do the same).
-It's logic that, while not in note input mode, navigation keys (Home, PgUp, arrows, ..) do not modify the score

> using "N" as a modifier would be almost completely undiscoverable by the average user

Note input mode itself is the very first "thing" that the average user has to "learn". And in this learning process he learns to use the N key to enter Note input mode. Learning at the same time that keeping it pressed puts you in Note input mode temporarily seems quite natural, and very easy to remember, same key N = NoteInputMode. Comparaison with ShiftLock (press N) and Shift (press N and keep it pressed) would make things clear, + hoverhelp text on the 'N' button in the palette.

> I do like the idea of having increased access to note input mode commands while not in note input mode

:-)

In reply to by frfancha

Yes, some things are different in note input versus not, but up/.down are comannds most people use many many many many many times. Changing the nice simple behavior of these would be a giant step backwards. It should be considered out of the question as far as I am concerned. These keys are to important, too commonly used, to want to sacrifice them for a slight improvement in some much less common corner case.

Yes, one has to learn note input mode, but it works in standard ways, and many people figure it out with a manual. It is a mistake to invent a new user interface control that no one has ever seen before and then require use of it for some crucial piece of functionality. That should also be considered out of the question.

In reply to by Marc Sabatella

This was an excellent discussion; I wish I had noticed it at the time. Let me chime in with the opinion that nudging is a very important capability, particularly when working with material close to publication. I go crazy trying to nudge lines into position (since they don't nudge).

Since we can't further overload the arrows, what about overloading the selection operation? Alt-click (or similar) any object/glyph to allow nudging with arrows to move larger amounts, ctrl-arrows to move fine amounts. Esc or click the canvas to stop nudging. This kind of repositioning mode would be familiar from other tools, and could have clear visual feedback so it wouldn't be confused with normal keybindings. It would also give a context for similar placement/appearance actions such as shrink/grow, rotate, opacity, color, reverse/invert....

In reply to by spinality

I go crazy trying to nudge lines into position (since they don't nudge).

Re: Nudging lines (e.g. slurs, ties, arpeggios, brackets, hairpins...):
https://musescore.org/en/handbook/edit-mode#lines

You can use the arrow buttons alone or in conjunction with Ctrl (or Alt for even finer control) of 'nudging'.
In edit mode, simply choose the "full object" handle - the one which slides the whole element.
(Or do I misunderstand?)

Regards.

Do you still have an unanswered question? Please log in first to post your question.