Incorrect layout of key signature in Continuous View if top staff has no key signature

Probably related. If you first switch to Continuous view, then you change the key, nothing happens. You have to switch back and forth to Page view to update the score.

The initial bug seems fixed. But vgstef one in #1 is not. I let this open for further investigation.

Regarding #1, same is true regarding change of initial clef - if you make the change while in continuous view, you have to leave & come back for it to take effect.

Though, the continuous panel is working fine!

All of this seems to stem from one central thing - the layout of key signature segments in continuous view appears to be relying entirely on the key signature of the top staff. If there is a key signature segment but no key signature in the staff - either because it transposes differently, or because it is a staff type that does not use key signatures - then the key signature is not seen. That means key signatures do not appear at all when added while in continuous view, and they are laid out incorrectly if you add one in page view and then switch to continuous.

I've never really looked at the continuous view code to understand how it relates to the "regular" code with respect to layout. But I'll see if I can sort this out.

First observation: this question appeared on 1 September.

- Between this commit, correct: https://github.com/musescore/MuseScore/pull/1246

- And this one, which could be the cause? https://github.com/musescore/MuseScore/pull/1248/files
or/and the previous? https://github.com/musescore/MuseScore/pull/1257/files

There are 8 commits (between the two first mentionned) the same day, but does not seem directly related?

That being said, it is possible that it is not enough to explain the question. Because, with the Beta1, the question appears already watermark.

In fact, if I add a fourth step (i.e. Undo) at this:
1. Open attached score (produced in 2.0).
2. Apply C♯ major key signature to bar 1.
3. Change to 'Continuous View'.
4. Undo

at this moment, the issue is already there.

And until September 1 in the same manner. Then it appears immediately, without the step of Undo, as described above.

I'll continue to investigate and go further to try finding the problem with this "Undo" (if it helps?)

Thanks as always for your analysis! It was the second commit - no key signature for drum staves - that first caused the issue in this particular example. However, it is possible to reproduce it with different steps that don't involve drum staves. The issue can be seen any time the top staff has no key signature. That could also happen if, for example, you create a score for two flutes in C major and then use Ctrl+drag to add a key signature to the second staff but not the first. The reasons for that have to do with a different change to how key signatures are stored.

I have already identified the portion of the code responsible for the original bug - including the comment in #1 and #4 - and have a fix I am testing. I am also working on a fix for the issue in #6, which is only sort of related, but does deal with the same basic area of code.

Ok, good new :)
So, after further investigation, and with this process:

1. Create a score for drumset + guitar tab + guitar standard
2. Apply C♯ major key signature to bar 1.
3. Change to 'Continuous View'.
4. Undo

I found this other issue (or a variation, or the introduction?, I do not know) occured on July 25.
This Nigthly was correct (after the step of Undo, I repeat) : https://github.com/musescore/MuseScore/pull/1067

This one was no longer:
https://github.com/musescore/MuseScore/commit/f97a8b22c681ee778e725e558…

There are three intermediate commits, but do not seem directly related?

-And the result (the same) with Beta1, after Undo

Thanks, my fix should solve these problems. It makes the layout less sensitive to the sorts of changes that caused these problems.

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

Fixed in 9d7185d89a

Automatically closed -- issue fixed for 2 weeks with no activity.