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

• Sep 17, 2017 - 20:49
Reported version
2.1
Type
Graphical (UI)
Severity
S5 - Suggestion
Status
active
Project

Observed behavior:
Select an object (e.g. a chord symbol, a text, ...) and use arrow keys ==> object is moved.
Select two objects (even of same type, e.g. 2 chord symbols), arrow keys don't work.
Expected behavior:
Arrow keys move the selected objects.


Comments

Severity S4 - Minor S5 - Suggestion

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.

In reply to by Robert Ingham

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.

In reply to by Marc Sabatella

In my specific use case which leads to this thread, the "problem" was that almost all (but not all) fingerings in the measures under a repeat line were colliding with the repeat line.
After having selected the colliding fingerings (by ctrl+click) I was hoping to move them all by arrow key.
Would have been very convenient if it was allowed...

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.

In reply to by frfancha

Oops I spoke too quick:
There is a big difference (apparantly, or am I wrong??) to the inspector method compared to what would be possible by arrow keys:
using the inspector forces offset of all selected elements to become equal ...
Using the arrow key on the multi selection would add or substract the same amount to the possibly different offset to begin with, that's something different.

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.

In reply to by Marc Sabatella

Thanks for the tip with the mouse, seems to be the solution, but in fact no: as soon as I begin to drag, the offsets of all selected elements are reset to the same values as the offsets of the element on which the mouse is.
At least it happens like that for chords in 2.1.
Before drag:
beforedrag.JPG
Just after very small drag of chord B:
just_after_very_small_drag_of_chord_B.JPG

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.

In reply to by frfancha

In Version 3, dragging with the mouse several selected chords doesn't work at all for me. The score is moved on screen instead.
And moving several selected elements such as chords by keyboard is still impossible, while moving them by keyboard one by one works like a charm. Frustrating.

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.

In reply to by Marc Sabatella

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.

Hi Marc,
I don't really get why you mention the inspector here.
Selecting one chord and moving it by arrow keys doesn't use the inspector, we just ask to be able to do the same with several selected chords.

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.

In reply to by Marc Sabatella

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,

In reply to by Jojo-Schmitz

In other software such as MS-PowerPoint, when you open an "inspector" with several elements selected, the properties with the same value for all selected elements render a normal UI, the properties with different values for the group of selected elements render an empty UI to show that a "common" value doesn't exist.
See here three elements with same horizontal position, but different vertical position.
And moving the three elements with arrow keys work perfectly, updating the horizontal position in "inspector" moving left and right, keeping the vertical position empty in inspector moving up and down.
Capture.PNG