Lines: when end handles are adjusted with keyboard arrows, anchor point also shifts
S5 - Suggestion
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 220.127.116.1199, revision: 43c5553
- Open the attached file.
- Select the start handle on the barré line and move it using the Right arrow, or Ctrl + Right arrow.
Expected result: Anchor point stays where it is.
Actual result: Anchor point moves to the next note.
See also: Don't move anchor points when hairpin ends are moved.
This is currently by design, but I agree it should be reconsidered as per the forum discussions.
In most cases, in order to keep the ends of the line, including "Begin" or "End" text, at the correct position, it is necessary to allow the anchor to snap to the following or previous note: not an ideal solution.
The use of arrow keys, and Ctrl + arrows, to adjust the handles, without affecting the anchors, needs to be restored.
In reply to AFAICS, the line anchor… by geetar
Exactly, this seems in line with what everyone has been saying, and I agree.
Possibly related to #309102: Lines: Dragging a handle causes anchor to shoot off in opposite direction; same thing when using keyboard arrows
This is really giving me some troubles today. I prefer the former behavior where I'm in control of anchors.
At least, there could be some kind of 'threshold' or tolerance before the grip jumps to the next or previous segment. Maybe dragging the grips should only change anchors when 'touching' or coming close to the center of a segment and not its boundaries - in a similar way that dragging slurs grips change only when touching a note.
Definitely, the arrow keys shouldn't change the grips unless using the proper key combinations (as in previous versions).
There should be a way to move an endpoint without the anchor moiving.
Related to #311174: [EPIC] UI/UX issues and suggestions
came up again: https://musescore.org/de/node/311820
This does BTW also lead to the crash from #313721: Dragging dynamics symbols from an empty measure into a multimeasure rest shuts down the program., when multimeasure rests are touched
My proposal is that we have all keyboard adjustments continue to not move the anchor, except of course Shift+Left/Right. So, Left/Right on their own or with Ctrl would be to line length only, no change of anchors.
For the benefit of mouse users, I would also propose a modifier to suppress the anchor change. Ctrl is already used to constrain dragging to horizontal only (relevant if the line allows diagonals), but I don't see any harm in having it also suppress anchor change. I might suggest Alt, since it is used during normal drag operations to disable autoplace and somehow this seems vaguely similar, but on my system, Alt+drag doesn't actually work because Alt+click activates popup menus. Probably there is some way for me to change that in my OS settings, but anyhow, right now I wouldn't have an easy way to test any change to Alt+drag.
BTW, the crash with dynamics is related in some way of course, but lines don't crash, only dynamics. So, not really related, I think the anchor rebase code for lines is more robust in the case of multimeasure rests.
Fixed in branch 3.x, commit f7245e989e
_fix #309368: suppress anchor change on keyboard nudge or Ctrl+drag
Currently, dragging or keyboard nudging the end handles of a line
will always try to find a new anchor point to attach to.
This makes it virtually impossible to obtain certain layouts
where you deliberately want a line to extend before or after a note
but still be attached to that note rather than the previous/next.
Thre solution here is to simply disable the rebase of anchords
when using the keybaord to perform the adjustment.
In addition, for mouse users, I allow the Ctrl modifier
(which also constrains drag to horizontal)
to perform this same function._
Automatically closed -- issue fixed for 2 weeks with no activity.