Shift / Control and dragging an element does not work (drags the score instead)

• Nov 28, 2018 - 10:49
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 747f3e9

Open the attached file. Press [Shift] or [Control] while dragging any element.

Expected result: As in 2.x, confines drag to the vertical or horizontal.
Actual result: The element does not move, but the whole score is dragged

Attachment Size
shift_control.mscz 11.17 KB

Comments

• Dec 3, 2018 - 20:03
Regression Yes ⇒ No
Workaround No ⇒ Yes
Priority ⇒ P1 - High

Works as expected for me. You need to press Ctrl/Shift after you start dragging (and change the position a bit). The issue is here, indeed. We need to stop process Ctrl/Shift as panning when mouse button down event was received.

Not a regression. There was no panning in 2.3.

Reply

• Dec 18, 2018 - 23:44
Regression No ⇒ Yes

Good to know the workaround exists. But for the record, in 2.3.2 you can press Shift or Ctrl first on an element and dragging still works fine, and Shift+drag also worked fine to pan the score. So this is a regression. I do recall a previous release having an issue with misinterpreting one or the other unless you pressed it afterwards. I think it was Ctrl, and the issue was that Ctrl+click would activate "add element to list selection" had a chance to start dragging. Somehow it seems that must have gotten fixed before 2.3.2, but now broken again for both Shift & Ctrl.

Anyhow, the relevant code is ScoreView::mouseMoveEvent in events.cpp, which I happened to be looking at for other reasons today, which is how this came up again.

Reply

• Dec 26, 2018 - 07:16

The problem with pressing shift/ctrl only after the item has started moving is that it is possible for the move motion prior to the keypress to happen along the undesired axis. I usually use the constrain dragging feature when I don't want an element to move even a single pixel either horizontally or vertically.

Reply

• Dec 26, 2018 - 15:30
Priority P1 - High ⇒ P0 - Critical

Agreed. I see no good reason not to fix this. Looking at the relevant code, it seems there were changes made do to general refactoring, making it hard to track things more specifically, but it seems more an oversight than anything intentional here. Right now this is on a very short of feature regressions, would be nice to eliminate as many of these as possible.

Reply

Fix version
3.0.1