Generated key signature and clefs not removed

• Nov 29, 2018 - 17:54
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

This is very likely related to #277956: Extra initial clef in scores imported from 2.x and #278993: deleting measures creates extra clef and key signature, but no import from MuseScore 2 is necessary to see the problem here.

1) load the attached score key-changes-3 (created from scratch with Beta)
2) delete the line break in measure 8
3) click the rest in measure 9 (now in the middle of the system rather than at the beginning of the next)
4) Alt+Left (moves cursor to previous element)

Result: there is an invisible G major key signature there. This was, I assume, the generated key signature that was originally present when measure 9 did start the system, and somehow didn't get deleted, it just doesn't actually display.

5) Alt+Left again

Result: there is an invisible treble clef there, presumably for the same reason.

The elements aren't displaying and also don't seem to be doing any harm, except to people using Alt+Left/Right to navigate their score (eg, the blind users for whom this shortcut was developed). And that's a serious problem in itself. But right now I'm more concerned about what iswrong architecturally - generated elements not being removed.

I tried to get things to screw up by inserting more key changes, clefs, or breaks before them but couldn't. These invisible clefs and key signatures stay right there. If I insert a change to Db major in measure 8, the G major key signature in measure 9 remains, but the measure does continue to act as if it is in Db.

However, if you try the same thing using the attached key-changes-232 (created, of course, in 2.3.2), there are some more obvious problems. First, try opening the timeline before opening the score. Look at the key signature section. When you first open the score, it shows only what you expect - the actual key changes. Hit "No" when asked to reset positions, and it stays that way. But, close the score, open it again, and this time hit "Yes". Now suddenly all the generated key signatures (start of each system) show up in the Timeline! I still can't get anything really bad to happen. But I have to figure this is all related somehow to other problems we see, so I'm rating this P1 for now.

Attachment Size
key-changes-232.mscx 15.41 KB
key-changes-3.mscx 16.14 KB

Comments

It seems that not removing generated system header is done intentionally — at least the code of Measure::removeSystemHeader explicitly marks the corresponding segments as disabled without removing any elements. These elements can be reused if system header is created at this measure again. Not sure whether such reusing is necessary but at least we need to fix the issue with Alt+left navigation.

For extra key signatures shown in the timeline see the PR for #277956: Extra initial clef in scores imported from 2.x.

I fear there are probably other places where these elements are not considered properly and we'll be fighting bugs about this for a while, but I can also see how it might be nice to reuse these elements, especially if they had had any customizations ad those get preserved - and indeed, that seems to be the case. So hopefully we are just careful!

So, the "enabled" flag for a segment is something we need to be checking before using elements on it - in general for all segments, or just clef/key/time signature segments? I see there are nextEnabled() and previousEnabled() methods, I guess we should probably in the habit of iteration using those, but I don't see a lot of that happening.