Fix #27317: color inversion incorrectly affecting palettes

[Reedbeta]

Resolves: #27317

Addresses certain elements of the palettes rendering in an incorrect color when score inversion is enabled.

Root cause of the issue

Items drawn under the palettes should not be inverted, as the palettes are drawn according to the overall app theme (light, dark, high contrast) and the appearance of palettes isn't meant to be affected by the invert score setting. To accomplish this, EngravingItemPreviewPainter has some code that overrides the color inversion flag right before it draws an element, then restores the original flag value after.

The problem was in two cases (that I know of), the inversion flag wasn't being propagated to related elements:

• Text line segments didn't propagate the flag to their begin and end text elements.
• Spanner segments didn't propagate the flag to their containing spanner. This affected Trill and Vibrato elements as they are drawn based on the spanner's color rather than the spanner segments' color (see SingleDraw::draw methods).

Approaches to fix

In this PR I did a "minimally invasive" fix, by adding logic to EngravingItemPreviewPainter to detect text line and spanner segments, and explicitly set (and restore) the flag override on the related elements.

However, I can also see an argument for making setColorsInversionEnabled a virtual method, and having each engraving item handle it similarly to setVisible, setColor, etc. That would be a much bigger fix, but maybe is more the "right" way to do it.

• 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)

[Reedbeta]

@cbjeukendrup Further thoughts on this PR? I know you'd prefer a cleaner solution, but it would be nice to get this fix in for 4.6.

[cbjeukendrup]

Yeah, let's just merge it. Would you mind creating a version for the 4.6 branch as well? Thanks!

[Reedbeta]

Yeah, let's just merge it. Would you mind creating a version for the 4.6 branch as well? Thanks!

Sure, PR opened for 4.6 here: #29468