GSoC 2020 Milestone 1: add style options for H-bar multimeasure rests

[IsaacWeiss]

Resolves: https://musescore.org/en/user/101731/blog/2020/06/01/gsoc-2020-day-1-it-begins

New Style page with new options:

Font-specific settings automatically applied:

This PR includes everything from #6108, with real changes actually beneficial to users now added.

• I signed CLA
• I made sure the code in the PR follows the coding rules
• I made sure the code compiles on my machine
• I made sure there are no unnecessary changes in the code
• I made sure the title of the PR reflects the core meaning of the issue you are solving
• I made sure the commit message(s) contain a description and answer the question "Why do those changes fix that particular issue?" or "Why are those changes really necessary as improvements?"
• I made sure the commit message title starts with "fix #424242:" if there is a related issue
• I created the test (mtest, vtest, script test) to verify the changes I made—TODO

[IsaacWeiss]

Ah, I see why vtests fail. As I allude to in the commit message (and will discuss in my blog post next week), I figured out that mmrests were being drawn with a difference between the visual ends of the vertical and horizontal strokes and the actual internal endpoints, due to Qt's default setting for lines being "a square line end that covers the end point and extends beyond it by half the line width" (see https://doc.qt.io/qt-5.9/qt.html#PenCapStyle-enum). For the vertical strokes, this meant that they stuck out just a tiny bit too far; for the horizontal, this meant some unnecessarily complex calculations in order to compensate. I changed both to Qt::FlatCap and was able to simplify. The differences that result should be for the better.

[AntonioBL]

@IsaacWeiss : I think there could also be a change in the mmrest skyline. If you look at bravura-mmrest, mmrest-8, mmrest-9, mmrest-10, the texts are now all shifted upwards.

[mattmcclinch]

I asked Tantacrul about adding a glyph for a multimeasure rest to the icon font, and he very kindly obliged. mattmcclinch@2f7dbaf contains the updated icon font and uses the new glyph for the multimeasure rest icon. You will need to rerun the install scheme or else MuseScore will load the old font with the missing glyph. It is up to you whether or not you want to remove the definition of IconNameTypes::IconNames::QUESTION_MARK. I think it can still be useful, even though this PR no longer requires it.

We can probably bring some of the new multimeasure rest options over to the inspector as well, but I thought I would share this much now, anyway.

[IsaacWeiss]

Fixed the skyline issue.

[MarcSabatella]

Looking good! BTW, for ongoing projects like this, I recommend not squashing commits until after code is code and reviews are satisfied and things are ready to merge. It makes it harder to track the discussions when comments end up being on outdated diffs, and I can't see what change you made to address any particular review (eg, how you fixed the skyline).

[IsaacWeiss]

Looking good! BTW, for ongoing projects like this, I recommend not squashing commits until after code is code and reviews are satisfied and things are ready to merge. It makes it harder to track the discussions when comments end up being on outdated diffs, and I can't see what change you made to address any particular review (eg, how you fixed the skyline).

I started out that way (initial version of #6108 was three commits), but when I kept having to rebase, it was much worse with multiple commits. Hopefully the huge changes to master will pause now, or this PR will be merged first.

[IsaacWeiss]

Speaking of risks with squashing commits, I squashed the two I cherry-picked from @mattmcclinch with each other, and that made me appear to be the author. The Inspector isn't really related to these Style changes—only the number position, which was previously implemented, really makes sense on a per-element basis—so I'll back that squashed commit out, and let @mattmcclinch make his own PR restoring the mmrest Inspector.

[MarcSabatella]

Good point about the rebasing, I guess that could be a special reason to squash more often this year in particular.

[IsaacWeiss]

At any rate, I think this is complete, and I hope it can be merged before it needs rebasing again. Since the old-style mmrests are something of a separate feature, I will be working on a new branch; if this PR is not in master by then, I will still try to keep them in a separate commit.

[ecstrema]

What about setLayoutInvalid? Doesn't trigger layout compute lots of things?

[mattmcclinch]

triggerLayout() is definitely the right method to use. setLayoutInvalid() only applies to elements that are subtypes of TextBase. And triggerLayout() does not exactly compute lots of things, but it does invoke a number of functions. It is all very fast, though.

[MarcSabatella]

More specifically, triggerLayout tells MuseScore to relay our exactly the part of the score that this element affects. So in most cases it means only a single system or page gets laid out after each change rather than the whole score.

setLayoutInvalid basically means, we need to relook at the content of the text element to reprocess all the formatting within in it.

[Harmoniker1]

Do you think the style options for rests should really be on a separate page? I have a PR #5602 a long time ago that added a style option for rests to the Notes page (renamed to Notes/Rests).

[MarcSabatella]

As I've mentioned (but seemingly not been understood) on Telegram, I'd prefer to see the existing style dialog be gutted and instead find a way to use the new Inspector to make style settings directly. Same code, same user interface; less maintenance, less user confusion; win/win. So that would render this question moot.

That said, notes & rests are different enough, especially their style properties, that to me keeping them separate makes sense if we stay with this dialog-full-of-pages approach. I think there should be other style settings for rests, like the offset applied in mutlivoice context, etc.

[IsaacWeiss]

To me it actually does make sense to have options for notes and rests near each other, I just somehow hadn't realized there was already a Notes page.

[IsaacWeiss]

Huh, apparently I have no idea how vtests work.

[AntonioBL]

The commit about vtests is useless.
Vtests are compared to the images from parent build, which are generated "on the fly" (i.e. mscore is compiled twice: the current PR and the parent branch, and vtest script is run on both).
The reference images are used only in http://vtest.musescore.org/index.html
A vtest "failure" is not necessarily an actual failure: it simply points out that vtests have changed because of the PR, so that the author (adn reviewers) can check and verify that the changes are not introducing visual bugs. It is possible, on the other side, that the changes actually improve the visual appearance of the tests.
If someone with the proper permissions adds the "vtests" label (I think the repository admin maybe should first create it) to the PR, then the emitted failure is skipped (but artifacts are still uploaded so they can be checked).
Ciao,
ABL

[IsaacWeiss]

Dropped the vtests commit and added one to make the new class [EDIT: and class Rest too while I'm at it] match the new style guidelines. This PR is now temporarily not in a state of merge-readiness, as the new commit is separate for clarity. Once squashed, this PR will again be finalized and ready for merging.

[IsaacWeiss]

This PR is now really truly finished.

[mattmcclinch]

If this PR is to be merged, it would be better if it included the version of editstyle.ui that can be found here. Then #6211 would only have to make these changes to that file.

[IsaacWeiss]

Given @mattmcclinch's reasonable point about the commit history of editstyle.ui, I've concluded it's impractical to keep multiple PRs open from different branches when the changes affect the same code.