I'm not understanding why you'd drag a chord rather than use the arrow keys. Seems the only reason might be to force things attached to also change position, in which case, this could be considered a feature, not a bug.
Let me put it another way: say the fix was to disable dragging completely? Would this be acceptable? If not, then there must be a use case you have in mind in which dragging is intended to accomplish something the arrow keys do not. Or perhaps you are wanting it to simply duplicate the arrow key functionality. That is what I am trying to understand.
Right now, the *only* such use case that comes to my mind is that if you wanted markings to move along with the notes, dragging might be a handy way to achieve that. In 1.3, it was apparently an undocumented / unsupported (as far as I know) way to achieve diatonic transposition, but in 2.0, that can be done by Shift+arrow.
Is there another use case you have in mind where you need some other unique property of dragging that works differently from the arrow keys? Or are you saying you want it to be implemented as an exact equivalent of the existing documented / supported Shift+arrow?
The point being, one can't define expected behavior without knowing the use case.
Dynamic layouting and collision detection keeps distance during dragging if autoplacement for the tempotext is set. If you manually adjust tempotext position, dragging note will collide the tempotext.
Comments
Also see #10662: [Trunk] Not all selected notes moved upon drag move
I'm not understanding why you'd drag a chord rather than use the arrow keys. Seems the only reason might be to force things attached to also change position, in which case, this could be considered a feature, not a bug.
The arrow keys are one way of doing it, but what if you drag and want the position of the tempo text to remain the same?
My question is, *why* are you dragging?
Let me put it another way: say the fix was to disable dragging completely? Would this be acceptable? If not, then there must be a use case you have in mind in which dragging is intended to accomplish something the arrow keys do not. Or perhaps you are wanting it to simply duplicate the arrow key functionality. That is what I am trying to understand.
Right now, the *only* such use case that comes to my mind is that if you wanted markings to move along with the notes, dragging might be a handy way to achieve that. In 1.3, it was apparently an undocumented / unsupported (as far as I know) way to achieve diatonic transposition, but in 2.0, that can be done by Shift+arrow.
Is there another use case you have in mind where you need some other unique property of dragging that works differently from the arrow keys? Or are you saying you want it to be implemented as an exact equivalent of the existing documented / supported Shift+arrow?
The point being, one can't define expected behavior without knowing the use case.
I can't reproduce. Please explain "2. Drag the first chord down."
Marc: I don't have a specific use case for dragging. I just saw it as an alternate way of moving notes.
lasconic: Sorry for the vague steps.
2. Drag-select the first chord.
3. Hold shift through the remaining steps.
4. Click and drag any of the notes in the chord up, or down.
Result: The Tempo Marking moves along with it (colliding with the staves).
Using MuseScore 2.0 Nightly Build (aac18be) - Mac 10.7.5.
Dynamic layouting and collision detection keeps distance during dragging if autoplacement for the tempotext is set. If you manually adjust tempotext position, dragging note will collide the tempotext.
Automatically closed -- issue fixed for 2 weeks with no activity.