Fix measure number layout order

[miiizen]

Resolves: #12955
Resolves: #23760

This PR adds measure numbers to the skyline after other elements, to avoid other elements moving to fit around them. It also improves the positioning of numbers in the first bar of a system.

[mike-spa]

Couple of things:

• I'm not a fan of using pairs for returning two values (a pair to me is almost exclusively associated with maps, whose elements are key-value pairs). I normally either create a struct to hold them, or make the function void and pass them in as references.
• It seems to me that this function is only really used in one place, where we then take the mid position of x1 and x2. At that point, I think it would be more elegant to call this function getMeasureVisualCenter or something like that and return the center point directly, rather than returning the two values

[miiizen]

The reason I opted to return two values instead of the centre of the bar is it's use in MeasureLayout::layoutMeasureElements where the values aren't always used to calculate a centre point (MMRests, measure repeats, measure rests). I'll try to get the same points just from the centre position - I agree it'll tidy things up a lot.
If I'm unsuccessful I agree on pairs, I'll use a struct.

[mike-spa]

No no, if there is a use for x1 and x2 that's different from just finding the center, then by all means let's have the function return x1 and x2. It just seemed to me that it was only used for the center but I might have just missed it

[mike-spa]

In other words, if the only use for x1 and x2 is to do center = 0.5 * (x1 + x2) then it makes more sense for this function to just return the center directly. But if x1 and x2 are used for other stuff, then it's fine as it is (but without using the pair for return)

[shoogle]

We shouldn't commit compressed files into the repository. I know other people have done it, but it's bad because:

1. We can't see what the file really is. It could be an executable for all we know.
2. If the file is changed later, we won't see what changed. Git will just say "binary file has changes".
3. It's annoying when parsing these files with programs besides MuseScore.

    # Find *uncompressed* scores created in MuseScore 3:
    grep -Flr '<programVersion>3' .
   
    # Find *compressed* scores created in MuseScore 3:
    find . -type f -iname '*.mscz' | xargs -I% sh -c "unzip -p % | grep -q '<programVersion>3' && echo %"

4. In the long run, compressed files take up more room than uncompressed files.
   • To save disk space and network bandwidth, Git stores deltas between changed files rather than the file itself. Deltas are calculated based on data rather than file paths, so even brand new files in the repository can be stored as a delta from existing data. And then Git compresses the deltas to save even more room.
   • However, if a file is already compressed then all redundancy is removed, so the file will have nothing in common with previous versions of itself or other files in the repository. In this case the delta is essentially the entire file, and Git's delta compression will be unable to compress it further.

[miiizen]

I agree with not being able to see the changes. All the vtests are compressed files as we need to test style settings too, so we'd need to make sure they work with uncompressed folders. We would also have to fix saving as an uncompressed folder, as this never works for me and saves a .mscz anyway.

[shoogle]

this never works for me and saves a .mscz anyway

What if you manually delete the .mscz file extension in the Save As dialog?

[henkdegroot]

Not sure if I will become of big fan of this change. I do appreciate the effort, but now the measenumbers are even placed above/outside the volta's. Looks really odd, specially when this happen at the tail end of a volta line.

[MarcSabatella]

Agreed, I don't think it makes sense for measure numbers to appear outside voltas. Most text also seems to make sense to appear above the measure number rather than vice versa.