Arrow keys doesn't move object when several ones are selected

This is currently by design. it's not inconceivable that this could be changed, but there are complications to consider. Text elements and rests are the only elements that can be moved in this manner, everything else requires the element to be in Edit mode. And only one element can be in Edit mode at a time. But we could indeed try special casing text to allow multiple elements to be moved with cursor only. Meanwhile, though, the Inspector works.

When editing the staff text properties, is it possible to make a vertical alignment change and tick a box to make the change to all selected text?

You can select several items of the same type and move them all at the same time using the inspector (F8 toggles its display)

aha, thank you, is it possible to get all selected items to snap to the same vertical alignment?

No, bit you can enable 'snap to grid' so you move with mouse only in steps or select several and set to the same offset

Perhaps more to the point, though, if you have a bunch of items you want positioned similarly, that's what Text Styles are for. If you literally want all staff text elements positioned in this new way, just edit the Staff Text text style. If it's just a subset of the staff texts but all ones that are "conceptually" similar - like they are indicating annotations to the score, say - then you can create a custom text style and apply that.

By "repeat line" do you mean a volta? Might be better to just move that instead. Anyhow, you can use the arrow key to move them at all once - just click in the appropriate field of the Inspector and use the arrow keys to change the value.

Also, instead of selecting the fingerings using ctrl+click, you can select the full measure(s) then right click on fingering use Select / All Similar Elements in Range Selection. Then Ctrl+click the ones you don't want to move, if any. This combined with the Inspector will be much more efficient than moving them individually.

Good point. In that case, you'll need t use the mouse. Hold Ctrl when you start the drag to keep all elements selected, then release it so you aren't constrained to horizontal motion only.

Ah, yes, true, sorry for misleading you. One at a time seems the only way then if you need to preserve the relative manual adjustments already made.

See #9347: ctrl-drag a group of objects should not first reset positions. I'm guessing there is a reason for this, as I noted when I submitted this years ago. But that doesn't mean it can't be revisited.

I think the reasoning hasn't changed since 2.0 (and the issue you link to predates that release by several years): now that we have the Inspector that shows offset values numerically, not resetting positions would be problematic in that it would mean the Inspector would be lying no matter what it shwoed, and in case, the Inspector remains the better way to do this sort of thing.

Allowing arrows to move multiple items would make it much easier to move like items up 1 space for example, while their offsets may vary from one item to another. We basically allow this for multiple notes (though the pitch changes with the location), why not for multiple text items? Pressing up arrow subtracts 1 from the x offset, ctrl+right arrow add 0.1 to the y offset and so forth.

The complication I mentioned is that the offsets for the markings would be different, so the Inspector would be lying. This isn't an issue for notes, because they would all have the same offset. That is, all notes start with offset off, so there is nothing to reset when moving them. Plus you aren't actually changing the offset. If the Inspector had a property "pitch" then we'd have the same issue the Inspector showing just one pitch even though they differ. It's not an unsolvable problem, but it is something that would need to be dealt with.

BTW, not sure why you'd be trying to drag notes, it's always "worked" but never been a good way of actually accomplishing anything that isn't better done through other means.

I was talking about the original topic, which wasn't about notes but about text and other elements. The Inspector is relevant to that, and I was also explaining why it is not relevant to using dragging as an alternate method of transposing notes.

As soon as you select two text items with different offsets, the inspector lies anyway. The fields that are different would ideally be blank to show this is the case, but an arbitrary item's offset is fine with me, I've learned to ignore it. So, the lying inspector is no excuse to say this isn't possible.

As I said, it's not unsolvable, just something to consider, and one reason why it hasn't been done already. The lying done on initial selection is handled differently in the code form the lying that would need to be done if we needed to support dragging this way,

Thou shalt not lie to an inspector

That's what I suggested as what MuseScore would ideally do.

Encountered this bug today in MuseScore 3.5.2, when attempting to vertically reposition several chord symbols on the same line.

It is much older though, at least since 2.1, probably ever since

Meanwhile, if the goal was to algin the chord symbols, MuseScore can do that automatically throughout the score if you set a maximum shift amount in Format / Style / Chord Symbols. Or to do it for just selected chords, you can set their offset in the Inspector.

COMMENT DELETED