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

fix #279967: image resize not correctly honoring aspect ratio #5731

Merged
merged 1 commit into from Nov 23, 2020

Conversation

Harmoniker1
Copy link
Contributor

@Harmoniker1 Harmoniker1 commented Feb 18, 2020

Resolves: https://musescore.org/node/279967.

A new member variable _aspectRatio of InspectorImage is added to remember the image's original ratio. It is also updated when "Lock aspect ratio" is checked in lockAspectRatioClicked(). The new two slots widthChanged() and heightChanged() help changing the value other than the one changed by user.

// lockAspectRatioClicked
//---------------------------------------------------------

void InspectorImage::lockAspectRatioClicked(bool clicked)
Copy link
Contributor

Choose a reason for hiding this comment

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

Should be:

void InspectorImage::lockAspectRatioClicked(bool checked)

Also, I suggest that you throw away the aspect ratio (i.e., reset it to a known ”invalid” value such as 0.0) when checked is false.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It should be clicked because that's what Qt uses.

And is there any real-world usage of throwing away the aspect ratio when it is false? If not, then I don't see the need of making the code more complex.

Copy link
Contributor

Choose a reason for hiding this comment

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

It should be clicked because that's what Qt uses.

No, it should be checked because that's what Qt uses and also because it's what makes sense. Think about it: When this function is called, it's always because the checkbox has been clicked (or otherwise manipulated by the user), but the checkbox is not always checked. That's what the parameter is there to tell you.

And is there any real-world usage of throwing away the aspect ratio when it is false?

It's an additional sanity check, and it will also be useful when saving to the score file (i.e., a value of 0 means don't save it).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm convinced of the first matter.

For the second matter, I think "additional sanity check" should only take place if it can prevent latent failures or crashes. And as I said, this fix has nothing to do with saving to score file. If a variable is intended to be saved to score, it should be defined in libmscore rather than mscore.

@Harmoniker1 Harmoniker1 force-pushed the image-resize branch 3 times, most recently from 3f564f7 to 493bce7 Compare February 18, 2020 15:41
@Harmoniker1 Harmoniker1 changed the title fix #279967: image resize not correctly honoring aspect ratio and staff space unit settings fix #279967: image resize not correctly honoring aspect ratio Feb 18, 2020
A new member variable `_aspectRatio` of `InspectorImage` is added to remember the image's original ratio. It is also updated when "Lock aspect ratio" is checked in `lockAspectRatioClicked()`. The new two slots `widthChanged()` and `heightChanged()` help changing the value other than the one changed by user.
@Harmoniker1 Harmoniker1 changed the base branch from master to 3.x May 28, 2020 09:00
@anatoly-os
Copy link
Contributor

@Howard-C I would leave inspector related changes to the new inspector. Moreover, this issue has probably been addressed there. What do you think?

@Harmoniker1
Copy link
Contributor Author

Not fixing it for 3.5?

@Harmoniker1
Copy link
Contributor Author

I'd suggest this go to 3.6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants