Horizontal constraint on dragged lyrics, please

Just bumping this:

scorster wrote >> I sure could be wrong, but I'm musing that users overwhelmingly want to constrain x when dragging a lyricule, i.e. to drag a lyricule left or right at it's current altitude. I see this every time with people I've coached in MuseScore. If the is the general exception, why not make that the default or via a preference as the preferred behavior?

I’d REALLY appreciate a preference that would allow me:
• an automatic x constraint on normal lyricule drags, chord symbol drags etc.
• Ctrl/Cnd override the constraint by providing free x/y dragging.

If lyrics, chord symbols and chord diagrams lived in automatically x-constrained "lanes" I would rarely need a modifier key for position editing (and as a Mac user I wouldn't have to remember to use Cmd instead of Shift—normal UX on MacOS employs the Shift as the modifier for constrainting x. Is that not true on Windows?)

And yes, I know I can adjust lyricules with arrows and via Inspector position property values. So there's no need to add those points into this thread.

Also, MuseScore Mac 3.6.2 designates the Command key for adding/removing adjacent or discontinuously selected elements. So if I Command click of two or more command-clicked lyricules (to select them) and then command-click one to commence the constrained drag, the MuseScore removed the clicked object from the selection and no drag of any fashion occurs. So with any multi-lyricule selection I must reorder my action to click-command-drag, or suffer the fate described above.

All this complexity goes away if Shift invokes the constraint, but I think there may be a QT cross platform issue with that.

Lastly, In MuseScore Mac 3.6.2 a Shift drag indeed constrains—but only vertically. As mentioned this is contrary to Jeff Raskin's humane interface. And apps often use a “majority wins” Shift-drag gesture ... where the predominant drag direction defines whether the constraint applies to x or y. (See Adobe Illustrator 1.0) In such a scenario, Shift handles all constained drags.

Simple.

scorster

Maybe my submitted chart I wasn't my best idea ...

Regarding arrow keys specifically, here are some behaviors observed today while working on a few scores.

I imagine some of the results are according to design, when that is clear I've marked NORMAL, but some behaviors are bugs or achieve some result I don't comprehend:

Staccato dot

Down / Up arrow keys: NORMAL moves object vertically
Right / Left arrow keys: Selects next or prior note

Mordent

Down / Up arrow keys: Works for a while that the reaches a limit and sticks 
Right / Left arrow keys: Selects next or prior note

Up bow mark

Down / Up arrow keys: NORMAL moves object vertically
Right / Left arrow keys: Selects next or prior note

Fermata

Down / Up arrow keys: no result
Right / Left arrow keys: Selects next or prior note

Slur

All Arrow keys NORMAL

Triplet bracket

 Down / Up arrow keys: moves only left control point
 Right / Left arrow keys: moves left control point

I would think they would work more line Volta or 

Accidental

Down / Up arrow keys: no result, which is interesting considering that drags are so slippery
Right / Left arrow keys: Selects next or prior note

The Dynamics I’ve tested

Down / Up arrow keys: NORMAL moves object vertically
Right / Left arrow keys: NORMAL moves object horizontally

Tempo

Down / Up arrow keys: NORMAL moves object vertically
Right / Left arrow keys: NORMAL moves object horizontally

SVG graphic

Down / Up arrow keys: 
    a) First arrow press selects bottom control point if unselected
    b) Up arrow scales SVG object smaller / Down arrow  scales SVG object larger

Right / Left arrow keys:
    a) First arrow press selects bottom control point if unselected
    b) subsequent right/left arrow presses have no effect

If right control point is manually selected
    Right key: scales SVG larger
    Left key: scales SVG smaller 

Chord diagram

No arrow keys have any impact

Chord symbol

All Arrow keys NORMAL