Don't move top system objects when rearranging staves #26134
+4
−31
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves: #25822
This has always been quite a buggy and confusing area of code. The general principle (as far as I understand) is that the "top" system object should not move when rearranging staves (cause it should just stay at the top of the score), whereas "non-top" system objects follow their stave, which makes sense.
But I've never understood why the condition of being top system object should be deduced from the linking properties. The fact that top and non-top system objects are linked to each other is a consequence, not a definition. Furthermore, linking has the additional complexity that links can exists within the same score, but also across score and parts (hence why this bug showed up in parts but not in the main score).
It seems quite clear to me that being a "top" system object should just mean being a system object at the top of the score (i.e. at track == 0). If it turns up that other parts of code relied on the previuos strange definition (which is likely), we'll fix those too.