fix #9013 Adjust dot placement for upward hooks #9095
Conversation
|
There are situations where the dot doesn't need to be adjusted, so this has been fixed with the most recent commit: |
|
|
| @@ -1365,6 +1365,7 @@ qreal Chord::defaultStemLength() const | |||
| } | |||
|
|
|||
| qreal normalStemLen = isSmall() ? 2.5 : 3.5; | |||
| /* We no longer need to adjust stem hight for dot-hook collisions (Issue #9095) | |||
There was a problem hiding this comment.
Better use #if 0... #endif. Here you' might be creating a compiler warning "comment inside comment"
There was a problem hiding this comment.
Better to remove this code completely
|
Rebase needed |
Backport of musescore#9095, fixes musescore#9013, part 1-3
Backport of musescore#9095, fixes musescore#9013, part 1-3
Backport of musescore#9095, fixes musescore#9013, part 1-3
Sometimes the flag doesn't necessitate moving the dots
Also, now that the hook isn't being adjusted, I increased the offset by 0.25sp to move the dot slightly further from the hook
asattely
force-pushed
the
dot-placement-for-flags
branch
from
b1e483a to
e1dd1b7
Compare
This comment was marked as resolved.
This comment was marked as resolved.
| // the top dot in the chord, not the dot for this particular note: | ||
| qreal dotY = chord()->notes().back()->y() + chord()->notes().back()->dots().first()->pos().y(); | ||
| if (chord()->dotPosX() < hookRight && dotY < hookBottom) { | ||
| d = chord()->hook()->width() + (0.25 * spatium()); |
There was a problem hiding this comment.
are both these 0.25 the same number? If so can't we consolidate those into one variable?
There was a problem hiding this comment.
They are not. The first one is adding a little bit of margin to the bottom of a hook for collision detection purposes (because otherwise they could be still right next to each other and not be technically colliding), and the second adds margin to the right side of the hook. Vertical vs horizontal positioning.
There was a problem hiding this comment.
Thanks for explaining.
Backport of musescore#9095, fixes musescore#9013, part 1-3
|
Checked #9013 on Win10. Hi @asattely , It's better than it was. But I think the dot can be too far from note in some cases and can collide with rests:
Even comparing with a desired result from #9013 : @Tantacrul @bkunda Please review |
|
Which might mean that we'd need 3 different distances, no hook (or hook far enough), half hook (desired 1) and full hook (desired 2)? |
|
This is very much an @oktophonie call |
|
Found a minor bug about shadow note dot position and real dot position. Logged separately #9265
|
|
Checked #9013 on Win10, Mac11.13.1, Linux Mint 20.2 - FIXED Please merge into master |
Backport of musescore#9095, fixes musescore#9013, part 1-3
Backport of musescore#9095, fixes musescore#9013, part 1-3
|
@igorkorsukov @Eism Please merge into master |
Backport of musescore#9095, fixes musescore#9013, part 1-3
Backport of musescore#9095, fixes musescore#9013, part 1-3
Backport of musescore#9095, fixes musescore#9013, part 1-3
Backport of musescore#9095, fixes musescore#9013, part 1-3
Backport of musescore#9095, fixes musescore#9013, part 1-3
Resolves: #9013
Quick fix to move dots over if the stem is up and there is a hook on the chord and the chord's dot placement is left of the right bound of the hook:
