Z-order for graphic elements

• Jul 21, 2014 - 15:57
Reported version
2.1
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Ubuntu Studio 14.04, GIT commit: d389ab2

1) drag attached graphic (a blank white square) to Promenade
2) drag it around

Result: the graphic obscures most score elements, but beams, articulations, and text sit on top

Expected result: not sure, but I'd propose, either the graphic obscures everything, or maybe text and perhaps lines should overlay the graphic. For 1.3, it seems the graphic would overlay the staff lines but be underneath everything else. That has a certain logic too. I do recall this having been discussed somewhere before, but not sure if there was an agreed-upon behavior.


Comments

https://github.com/musescore/MuseScore/pull/1055

Trickier to deal with than I might have expected, but this PR does the job, and has the hopefully-beneficial side effect that exported PNG and SVG files now honor the Z order as well (they did not previously; elements were drawn in a different order than screen or print rendering).

I chose to set the Z order for images by leaving the Element::Type list alone but instead explicitly calling setZ() in the Image constructor. I did verify it also seems to work to simply move IMAGE later in the Element::Type list - to right before MEASURE, but Werner advised against changing that order, so I went with lasconic's suggestion to use setZ() instead. Either way, MEASURE seems to be as high as it makes sense to set the Z for any object you need to be selectable, because otherwise you can't select any part of the object that lies within the bbox for any measure.

BTW, my PR includes a vtest, but it doesn't yield an empty diff - the Image objects themselves show as different. But visually I can see it works (given that I included a fix for the PNG export issue as well), so i am hoping this is just an anomaly of how the ImageMagick comparison is performed.

image-1-ref.png

Attachment Size
image-1-ref.png 8.63 KB