It sometimes comes up that the best way to solve some particular problem
would be to attach a symbol to a barline
(eg, think about the commonly-requested multimeasure repeat symbol).
But we don't support symbols on barlines, so you end up settling for
attaching to the first note or rest in the bar then moving manually,
and this adjustment does not necessarily survicve layout changes.
This commit adds direct support for symbols on barlines.
Also images, since the code involved is so similar, they are handled here as well.
Symbols and images are recorded as child elements,
which were already being laid out so no special handling was needed
beyond adding & removing, reading nd writing.
Although I did need to make sure the track & score were managed correctly.
Copying and pasting a breath mark on the last tick of a measure resulted in an empty Breath segment being created in the next measure. This is because the last tick of one measure is equal to the first tick of the next measure, and Score::tick2measure() always returns the second measure in this case. When the Breath mark actually gets added to the score in Score::undoAddElement(), a new segment for it is created in the previous measure. This is the measure in which we should be adding the segment in the first place.
Comes from https://musescore.org/en/node/290398#comment-940605. This can cause a serious delay on big scores.
The idea of fixing is changing the score()->setLayoutAll() to triggerLayout() in the functions of dropping and editing spacers. triggerLayout() will only do neccessary partial layout.
and use "8va" for ottava bassa if not just number to match the handbook
https://musescore.org/en/handbook/3/octave-lines
and also the 2nd preference from Elain Gould's "Behind Bars":
1. 8
2. 8va
3. 8va bassa
4. 8ba
Note: 8vb is not amongst those...
Why this is happening
In collectNote() in rendermidi.cpp, grace notes are currently not treated as notes that could potentially have forward ties; in fact, it is assumed that they will not. When a note is encountered that ties back to a previous note, it is assumed that the length of the note has already been added to the previous note, when in fact this is not the case if the previous note is a grace note.
Why this commit fixes the issue
The code for computing the entire length of the tie chain is now executed whether the current note is a grace note or not.
Provide Note.tieBack & Note.tieForward properties and their
associated Tie objects in QML. Also provides Note.firstTiedNote
and lastTiedNote methods to locate a tie range.
for some strange reason `QList::size()` returns `int` rather than
`size_t`, IMHO a bug in Qt, as even a `QList` can't have a negative
number of members.
And fix another warning reg. shadowing a local variable as well as reg.
some unused parameters
In https://github.com/musescore/MuseScore/pull/4866 I added code
to better handle the detection of the end of the layout range.
Part of this was to re-establish the header in the first measure after the end of the range.
But my code mistakenly passed in lc.firstSystem as the firstSystem parameter.
Thus it treated the *second* system as if it was the first,
since lc.firstSystem was set based on the system we just completed,
not the system we are about to consider.
Fix is to calculate when this new system is actually the first system of a section or not.
I calculate this the same way lc.firstMeasure itself is calculated.
As of Qt 5.12.4 OpenSSL version 1.1.1 is needed.
Detect/copy old/new SSL DLLs depending on Qt version to save space in
the resulting package.
For Qt >= 5.12.4 dependencies.7z needs to get updated to include those
new DLLs, attached to the issue,
https://musescore.org/en/node/291079#comment-940153
