split / join measures in parts

[sammik]

Resolves: #17115
Resolves: #19283

split and join measures now always acts in masterScore (under the hood)

In joinMeasure it was deleteMeasures used before, to handle parts.
But it has side effect, that it also creates "lastDeletedKeySignature" in next measure.
This was fixed by InsertMeasureOption "moveSignaturesClef" (by omitting moveSignaturesClef = false).
But it has side effect, that if "next measure" already contains key signature, it is moved too (#19283).

Now undoRemoveMeasures function is used instead of deleteMeasures.

(Thats why utests failed - in undoRemoveMeasure, there is no check of missing initial key signature, so joining first two measures in score with no initial key sig doesn't create new one.)

Also correct repeat barlines are preserved now.

• I signed the CLA
• The title of the PR describes the problem it addresses
• Each commit's message describes its purpose and effects, and references the issue it resolves
• If changes are extensive, there is a sequence of easily reviewable commits
• The code in the PR follows the coding rules
• There are no unnecessary changes
• The code compiles and runs on my machine, preferably after each commit individually
• I created a unit test or vtest to verify the changes I made (if applicable)

[sammik]

@cbjeukendrup I have also fix to #19323
Please, should I push it here, as it is related too, or better to wait and create separate PR later?

Thank You

[cbjeukendrup]

It looks like we should not call startCmd and endCmd inside this method. They are already called outside it.

[sammik]

@cbjeukendrup
Removing them caused utest spanners fails.
So I added them into test file.
Not sure, if it is OK (in case, if user would call joinMeasure or splitMeasure from command line)

[cbjeukendrup]

@sammik Perhaps there is an even safer way to do this: make cmdJoinMeasures and cmdSplitMeasures only methods of the MasterScore class. That way, you can be certain that nobody will ever forget to cal mScore->... if these methods ever need to be modified. What do you think about that?

[cbjeukendrup]

I have also fix to #19323 Please, should I push it here, as it is related too, or better to wait and create separate PR later?

A separate PR would be great!

[sammik]

@sammik Perhaps there is an even safer way to do this: make cmdJoinMeasures and cmdSplitMeasures only methods of the MasterScore class. That way, you can be certain that nobody will ever forget to cal mScore->... if these methods ever need to be modified. What do you think about that?

@cbjeukendrup yes, I agree, I was thinking of it too
please check now

[cbjeukendrup]

And it looks like another rebase is needed since #19245 was merged

[sammik]

And it looks like another rebase is needed since #19245 was merged

Rebased and also changed joinMeasure in favour of #19245 (add new measures first, and delete old after, to prevent adding default initial key and time in some cases)