Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calculate rest vertical adjustment after cross staff stem layout #19828

Merged
merged 4 commits into from
Nov 10, 2023

Conversation

miiizen
Copy link
Contributor

@miiizen miiizen commented Oct 25, 2023

Resolves: #19598
Resolves: #18555
Resolves: (see image)

Enables our rest & beam collision avoidance for beams which are completely moved to another staff and for upstemmed beams where the first item is a rest.

Screenshot 2023-11-01 at 16 50 50

  • I signed the CLA
  • The title of the PR describes the problem it addresses
  • Each commit's message describes its purpose and effects, and references the issue it resolves
  • If changes are extensive, there is a sequence of easily reviewable commits
  • The code in the PR follows the coding rules
  • There are no unnecessary changes
  • The code compiles and runs on my machine, preferably after each commit individually
  • I created a unit test or vtest to verify the changes I made (if applicable)

@miiizen miiizen marked this pull request as draft October 25, 2023 14:05
@miiizen miiizen marked this pull request as ready for review November 1, 2023 17:25
@oktophonie oktophonie added the vtests This PR produces approved changes to vtest results label Nov 8, 2023
// Pad rest shape by small amount so horizontal distance between rest and beam is more than 0
// A horizontal distance of 0 counts as no vertical collision
RectF bbox = restShape.bbox();
restShape.addBBox(RectF(bbox.topRight(), PointF(bbox.bottomRight().x() + 1, bbox.bottomRight().y())));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of just + 1, might it be desirable to add some spatium-based value? Or does it really not matter?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@miiizen this is a good thing to do, but:

  • Like Casper said, please use a spatium-based value for this padding and give it a descriptive name.
  • This implementation (adding a rectangle to the Shape that's slightly larger than the Shape itself) is quite hacky. It would be better (and probably also useful in general) to change the verticalClearance method to something like Shape::verticalClearance(otherShape, minHorizontalDistance), where minHorizontalDistance default-initializes to zero so it doesn't change where it's already used. Then, inside verticalClearance, you can add minHorizontalDistance to the left/right edges as needed before checking intersections :)

@cbjeukendrup cbjeukendrup merged commit 888fc7a into musescore:master Nov 10, 2023
10 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
vtests This PR produces approved changes to vtest results
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Vertical spacing bug rests vertical disalignment under same beam
4 participants