Hairpins dragged from palette always blue (as if selected)

• Aug 28, 2015 - 17:34
S4 - Minor

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


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.

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.

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:…

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

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().

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