Anchors appear on wrong page when moving elements items on page > 1
Reported version
3.x-dev
Priority
P1 - High
Type
Graphical (UI)
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
Hi there,
Got anoter regression in new alpha release.
Reported version:
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.0.11614, revision: 1ee2fe3
Anchors do not appear at the right place when moving tempo items.
1) add a new tempo item (like quarter = 80)
2) select and move the tempo item (e.g. attachment)
The anchor appears outside the score (e.g. attachment).
Many thanks.
| Attachment | Size |
|---|---|
| Sans-titre-2.png | 6.02 KB |
Fix version
3.5.0
Comments
Confirmed, seems to apply to elements on pages after the first, the offset seems to be wrong by the number of pages past the first we are (eg, one page 2, it's off by one page, on page 3, it's off by two, etc). Something like that anyhow. Also, it's not just tempo, but also dynamics, staff text, etc. Also articulations, fret diagrams, probably other element types - but not lines, where are drawn correctly. This suggests to me the problem is in some general code in Element class perhaps that is overridden in Spanner or SLine.
No crash or corruption that I can see, so I wouldn't call it critical, but it's something we should fix.
Sure, just critical for composers ;-)
Thank you Mark.
It happens also, for example, for dymanics.
After a git bisect, I found that it was introduced by commit 4c5e9ed2736 as part of PR https://github.com/musescore/MuseScore/pull/5738
Pretty clearly, the page offset is being added in twice, but I'm not totally sure which is the right place. See my comment at https://github.com/musescore/MuseScore/pull/5738/files#r432963951
That additional shift is necessary when dragging a "line", for example when dragging a hairpin (as a whole, not only its end points), so that its "attach" points are visible.
Maybe this shift should be moved inside overridden dragAnchorLines() function for lines only.
We should check which other elements need this additional shift.
See https://github.com/musescore/MuseScore/pull/6156, apparently I got confused with using different coordinate systems while working on the anchor lines PR.
Fixed in branch 3.x, commit 3b8f312c05
_fix #306096: fix incorrect anchor lines coordinates for some element types
In the process of anchor lines reworking some elements appeared to use
page coordinate system to describe their anchor lines coordinates while
others continued using canvas coordinate system. 4c5e9ed2736 fixed this
issue wrongly effectively swapping element types having the incorrect
coordinates issue. This PR fixes this inconsistency by ensuring using
canvas coordinates for this purpose._
Fixed in branch 3.x, commit e3416dd48b
_Merge pull request #6156 from dmitrio95/306096-anchors-coordinates
fix #306096: fix incorrect anchor lines coordinates for some element types_
Automatically closed -- issue fixed for 2 weeks with no activity.