Move element left/right (shift+arrow key) should work on all selected dynamics

[wizofaus]

Your idea

Would like (and indeed, expect) that if multiple elements (e.g. dynamics) are selected across multiple staves, that I can use shift+left or shift+right to move them all in parallel, rather than only the last selected one.
I'd also like to be able to use this feature if I've selected dynamics via the keyboard or "select similar" command etc. (AFAICT, currently it only works on the dynamic most recently clicked on with the mouse).

Problem to be solved

For dynamics in particular, when added to the end of a measure (after a dim. or cresc.) the default positioning is often not ideal, and in a large orchestral score you'll often have 6+ staves all with the same problem. Being able to select the dynamics for all of them and shift them left or right as needed at once would be a time saver (and, I'd say, what a user might reasonably expect to happen given you see they're all selected, and most other similar commands do operate on all selected items).

Prior art

No response

Additional context

In general I would think any command that can operate a single selected element could and should logically operate on all selected elements.

Checklist

• This request follows the guidelines for reporting issues
• I have verified that this feature request has not been logged before, by searching the issue tracker for similar requests

[Magnus26]

I think Alt should be involved in moving objects since Shift+arrow key is used for selections in most word processors.

[wizofaus]

You can always re-assign the default shortcut key. But it's irrelevant to how the command behaves.

[Magnus26]

It is not irrelevant how most word processors execute commands since those programs are so much used and familiar to most computer users.

[wizofaus]

Most (all?) word processors do indeed apply commands to all selected items/text, which is all I'm suggesting the behaviour of MuseScore should be. The shortcut keys used to access commands can be customised easily enough, but if you think the default assignments should be changed by all means raise a separate request.

[FrancRos31]

I think if the offset problem isn't resolved (#22622), all this placement issues can't be implemented to the best.

[bkunda]

In your title, did you mean to write "notes", or would it be more accurate to say "elements" (or something similar)? I would expect that notes would not be included in the proposed behaviour at all.

It seems to me that using the arrow keys to change the position of elements in a list selection does indeed only perform that action on one item (even though multiple remain selected). This is a bug, not a feature request.

Seems related to this idea: #24119.

At any rate, this issue might need to be rescoped/reclassified for accuracy.

[wizofaus]

Sorry, yes have changed to "elements".
Being able to nudge multiple notes with various keyboard shortcuts would also be useful but less of a priority.
And yes I would agree it's "unexpected" behaviour but I suspect it was only ever initially designed to work on a single element.

[wizofaus]

The strange thing is there are actually two commands bound the the shortcuts shift+left and shift+right, but NEITHER of them seem to be related to moving dynamics etc.:

@Magnus26 - I apologise, it appears you can't remap the shortcut key for this action at all, it's hard-coded special case code for dynamics.

@bkunda - do we need to revisit the fact shift+cursor keys seems to do at least 3 separate things, and as I just noted, for the case of shifting dynamics it appears to be hard-coded special logic, rather than a command you can bind to a shortcut key?
The code was obviously written with the expectation it would only apply to the current "edit element" (which there can only ever be one of). Rewriting it to apply to all selected elements is not entirely trivial. In fact in general the moment you click on a dynamic it becomes the current "edit element" and captures most keyboard input, preventing commands from working on other selected elements.
And indeed because of this, if you select the dynamics via the keyboard, or say the "select similar" commands, these commands don't work at all, even if a single dynamic is selected.
So that would seem to be a far more serious issue.
BTW for the other two commands bound to shift+left/right, the "move chord/rest left/right" commands ONLY work in note input mode, and only work within the same measure, and if the adjacent note/rest is exactly the same duration. Whereas "extend selection" commands only seem to work sensibly if you have a note selected (or a range). When I tried with a slur selected it disappeared entirely...

[Magnus26]

@Magnus26 - I apologise, it appears you can't remap the shortcut key for this action at all, it's hard-coded special case code for dynamics.

Apology accepted. Thank you for looking into all this and bringing attention to it.