Confirmed. It's only *while* dragging, and edit mode & Inspector both work normally. The algorithm for drawing the measure rest is kind of odd - it has to happen somewhere different from other notes because it displays at the "wrong" position for its segment, so I guess that's the source of the problem.
I think it happens at rest.cpp:354
(in Rest::layout()):
{syntaxhighlighter }
rxpos() = 0.0;
{/syntaxhighlighter}
The x position is set to zero while dragging, which only affects full measure rests since the x position of other rests is already zero. If this is the case, is this line necessary?
But commenting out that line doesn't seem to break that fix again. Maybe that line is no longer needed, but it would be good to understand. I suspect maybe changes elsewhere to the layout of full measures rests has rendered this unnecessary, but I can't say for sure. If nothing else, it should be safer to set rxpos() to 0 *if* the rest is not a full measure rest.
FWIW, though, layout() isn't called just during dragging; it's called any time we need to calculation position. So changing things here won't just affect drag - it will potentially affect all layout. Meaning it's important to test thoroughly.
I had to revert this. It somehow breaks some tests beyond repair but I believe it just reveal another bug. Let's take a look later when the layout code is more stable.
Comments
Confirmed. It's only *while* dragging, and edit mode & Inspector both work normally. The algorithm for drawing the measure rest is kind of odd - it has to happen somewhere different from other notes because it displays at the "wrong" position for its segment, so I guess that's the source of the problem.
I think it happens at rest.cpp:354 (in Rest::layout()):
{syntaxhighlighter }
rxpos() = 0.0;
{/syntaxhighlighter}
The x position is set to zero while dragging, which only affects full measure rests since the x position of other rests is already zero. If this is the case, is this line necessary?
Good question. According to the git "blame", that line was added in the following commit:
https://github.com/musescore/MuseScore/commit/4c7c05a6eedb6b60295ac82d4…
which was done to fix the following bug:
#18187: rests not placed correctly
But commenting out that line doesn't seem to break that fix again. Maybe that line is no longer needed, but it would be good to understand. I suspect maybe changes elsewhere to the layout of full measures rests has rendered this unnecessary, but I can't say for sure. If nothing else, it should be safer to set rxpos() to 0 *if* the rest is not a full measure rest.
FWIW, though, layout() isn't called just during dragging; it's called any time we need to calculation position. So changing things here won't just affect drag - it will potentially affect all layout. Meaning it's important to test thoroughly.
During dragging, Rest::layout() is called from Rest::drag(). Otherwise, the change in position seems to be immediately overriden by the code in Mesasure::layoutX():
https://github.com/musescore/MuseScore/blob/master/libmscore/measure.cp…
(This is not called while dragging the rest.)
Can Rest::layout() be called in different circumstances?
PR: https://github.com/musescore/MuseScore/pull/2424
Fixed in branch master, commit f329d193e1
fix #43306: while dragging a full measure rest, it gets displayed to far to the left
Fixed in branch master, commit fce7207e93
Revert "fix #43306: while dragging a full measure rest, it gets displayed to far to the left"
This reverts commit f329d193e174cfb9841e7b4a02b3e2db9262a556.
I had to revert this. It somehow breaks some tests beyond repair but I believe it just reveal another bug. Let's take a look later when the layout code is more stable.
It is time to take a look :) The drag limits are indeed weird in current master.