Hairpins dragged from palette always blue (as if selected)

• Aug 28, 2015 - 17:34
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

At least in recent nightly builds, hairpins are always blue, the exact same color whether or not they are selected.

Comments

• Aug 28, 2015 - 18:50
Title Hairpins always blue (as if selected) ⇒ Hairpins from palette always blue (as if selected)

My bad—it's actually only the hairpins from the palette (doesn't happen with keyboard shortcuts). Can you reproduce with those? Any score should work.

Reply

• Aug 28, 2015 - 19:14
Title Hairpins from palette always blue (as if selected) ⇒ Hairpins dragged from palette always blue (as if selected)
Status (old) needs info ⇒ active

OK, I can reproduce. Only for adding from palette by drag & drop, and only for true hairpins. No prpblems with shortcuts or with double click, and no problems for the new crescendo/diminuendo lines even with double click.

Reply

• Aug 29, 2015 - 05:28
Status (old) active ⇒ patch (code needs review)

This is interesting (from a development standpoint, anyhow).

The problem started when I changed Hairpin to inherit from TextLine rather than plain SLine. TextLineSegment defines its own version of setSelected(), which does not call SpannerSegment::setSelected(). This is bad, I think - it means when you select or deselect a textline (including ottava & pedal lines), the segment gets marked as selected or deselected as appropriate, but the state of the parent spanner never changes. I'm pretty there are other issues, probably involving Inspector glitches, that are due to this.

BTW, the reason the problem is only when dragging from the palette is that this is the only method that normally selects the parent spanner, so it starts selected and stays selected. With the other methods, it starts unselected and stays unselected,.

So the real fix, I think, is to change TextLineSegment::setSelected to call SpannerSegment::setSelected(). This would fix any other glitches that are due to this same underlying cause.

But this doesn't totally explain everything - why were ottavas, pedals, and other textlines not showing the exact same problem? Turns out that is because HairpinSegment defines it's own version of draw(), which manages color somewhat differently from TextLineSegment::draw(). In particular for this situation, TextLineSegment::draw() sets the color here:

https://github.com/musescore/MuseScore/blob/34838db48b60f019c0222e443c9…

and then uses the value of normalColor to override the color when it counts:

https://github.com/musescore/MuseScore/blob/34838db48b60f019c0222e443c9…

I've noticed this code before and never quite understood why we set color indirectly in this fashion. Maybe a holdover from some previous code?

Anyhow, here is a PR that makes both of these changes: calling SpannerSegment::setSelected() from TextLineSegment::setSelected(), and reproducing the "normalColor" code in HairpinSegment::draw().

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

Both changes make sense to me, but I could definitely use another set of eyes, as it all seems kind of odd to me.

Reply