MuseScore UX discrepancies
Please see attached score for Arrow Key UX descriptions.
MuseScore UX Arrow Key discrepancies.mscz
If find LOTS of issues like this afoot. Is it recommended that I start a new thread for each or is it acceptable to heap them here into this thread?
Thanks to all!
scorster
Comments
But this into the issue tracker, one issue at a time (this here is one, with several facettes)
This is actually by design, refined over the years by much feedback from many users based on actual use cases. Of course, like any design, it's subject to further refinement, but it is important to understand the decisions are not arbitrary.
Up/down are used both for symbols and for notes to alter them, left/right are used both for symbols and notes to navigate. That's because navigation is much,l much, much more common, and needs to be made very easy. And as for adjustment, modifying vertical properties (position or pitch) is similarly much, much, much more common than modifying horizontal ones. So again, we want to make the common operations as easy as possible.
To move any element in any direction, double-click it to put it into edit mode. This disables the normal navigation functionality and dedicates the arrow keys to position only. And in the case of notes, it also makes their meaning consistent with both symbols - adjusting position, not pitch.
As for behavior of up/down with multiple selection, this isn't implemented, in part because over the years people couldn't agree on the exact expected sematics if the elements are not currently aligned already. But the Inspector works on different principles - setting an absolutely offset - so that has a clearer semantic, and is thus implemented accordingly.