Lines: when end handles are adjusted with keyboard arrows, anchor point also shifts

• Aug 20, 2020 - 13:09
Reported version
3.5
Type
Functional
Frequency
Few
Severity
S5 - Suggestion
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.0.13199, revision: 43c5553

  1. Open the attached file.
  2. 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.

Attachment Size
anchor_point_jumps.mscz 6.36 KB

Comments

• Aug 21, 2020 - 21:38

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.

Reply

• Sep 14, 2020 - 00:45

+1

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).

Reply

• Dec 28, 2020 - 18:16

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.

Reply

• Dec 28, 2020 - 18:20

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.

Reply

• Dec 29, 2020 - 16:13
Status PR created ⇒ fixed

Fixed in branch 3.x, commit f7245e989e

_fix #309368: suppress anchor change on keyboard nudge or Ctrl+drag

Resolves: https://musescore.org/en/node/309368

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._

Reply

Fix version
3.6.0