__References__:
Issues: https://musescore.org/en/node/19155https://musescore.org/en/node/22861https://musescore.org/en/node/23100
__Description__:
Allows to change the start and end note to which a glissando is anchored after it has been entered. Either anchor can be changed independently.
The user interface follows the current working of other 'snappable' lines. Once either the start or end grip is selected:
- `[Shift]+[Left]` snaps the anchor to the previous chord, defaulting to its top note.
- `[Shift]+[Right]` snaps to the next chord, defaulting to its top note.
- `[Shift]+[Up]` snaps to the note above (possibly in a chord, voice or staff above the current one).
- `[Shift]+[Down]` snaps to the note below (possibly in a chord, voice or staff below the current one).
This permits to set the anchor points of a glissando to any note in the score, allowing several glissandi between the notes of the same two chords and other complex configurations (glissandi skipping intermediate chords, start and end notes in different voices or staves, and so on).
It is possible to move the anchor to a different staff of the same instrument, but not to a different instrument; also, it is not possible to 'cross' a change of instrument in the same staff.
__Known limitations__:
- The `[Shift]+[Up]` and `[Shift]+[Down]` use the same note-finding functions as the `[Alt]+[Up]` and `[Alt]+[Down]`actions which move the selection cursor to the above and below note, even across voices or staves. Occasionally, in particular if the note immediately above or below is not time-aligned, the algorithm has little expected results; however, the behaviour is already known to the user. Improving the algorithm would benefit both uses.
__Notes__:
- Most of the added infrastructure is not specific to glissando but to any spanner anchored to notes, then it should also add after-the-fact "snap to" note support to note-anchored text line.
- When moving an anchor, the algorithm usually prefers a note in the same voice/staff of the old note if it exists; if there is none, it tries other voices of the same staff.
- The change of anchor is undoable.
- The fix corrects the management of the `Chord::_endsGlissando` flag, taking into account that a chord can be the ending point of several glissandi and removing one of them not necessarily means the chord no longer ends a glissando (another glissando may still exists).
- The fix also improved the rendering of the glissando wavy line, with better alignment with anchor notes and, with glissando text, better text-line spacing.
Original issue: http://musescore.org/en/node/49881
Adding a glissando to a note encompassing intervening notes in other voices or staves of the same instrument, the glissando ends into the first intervening note in another voice / staff, rather than on the 'obvious' end note in the same voice / staff.
Fixed and added more tests for these cases.
`scanElements()` was scanning glissando segments both through the `Glissando` and through the system each segment belongs to.
Original issue: http://musescore.org/en/node/49136
**Common part**: Both issues stemmed by the fact that clicking a glissando sometime selected the whole `Glissando` and sometime one of its segments.
It depended on the order in which element types appear in `element.h` enum: for all other spanners the segment type is listed **before** the whole element type, while for `GLISSANDO` and `GLISSANDO_SEGMENT` it is opposite.
Changing the order ensures that the segment is always selected rather than the whole `Glissando` element.
**Inspector**: adding property management to `GlissandoSegment` routing whole `Glissando` properties from the segment to the `Glissando` fixes `Glissando` access in Inspector once one of its segment(s) is selected.
This is parallel to how other spanners are currently managed (see for instance, `TextLine` and `TextLineSegment`).
**Dragging** and Saving: fixed by treating glissando segment user offset as user offset rather as position component (parallel to how VOLTA is managed).
*) Old scores:
- grace_before-to-note glissandi in old scores are read correctly.
*) New glissandi involving graces
- In all cases, the ending note is identified correctly in the main chord, in the next main chord, in the graces-after of the main chord, in the graces-before of the next chord, whichever comes first.
- Spacing of cases involving graces-before is correct.
*) Spacing of cases involving graces-after.
It is not always optimal, as layout of graces-after pushes them as to the right as possible.
So, for instance, when a glissando is added between a grace-after of a chord and the next chord, the additional spacing added before the next chord to accommodate the gliss. is skipped by the grace-after.
I took the decision to ignore such cases as the usage of grace-after and of glissando has a very little intersection. Those cases will need manual adjusting.
- Implemented as a sub-class of `SLine`.
- Anchor type changed from CHORD to NOTE: allows to attach glissando start and end points to individual notes, rather than generically to chords (with note within the chord chosen by the program).
- The Glissando element is now stored in the `Note::_spannerFor` list.
- `Chord::_glissando` has been removed and replaced by a `bool _endsGlissando`, recording whether the chord is at the end of glissando (as gliss.-end chords require more space if mid-measure or system-initial).
- Debugger UI for `Chord` updated accordingly.
- Glissando in now save into score file as a spanner, within the initial note, and with appropriate `<endSpanner>` tag in the Glissando ending note.
- Existing scores with the old Glissando file format are correctly read back.
Notes:
- MusicXML import/export of the new Glissando implementation NOT IMPLEMENTED.
- This version can read scores from older versions, but older versions **cannot read** scored from this version (they do not expect a <Glissando> tag within a Note). Does this require a NEW FILE VERSION NUMBER?
- This implementation would allow rather easily to move the start and end anchors around (as for slurs) to override the note/chord chosen by the program when the glissando is initially created; but the UI for this is not implemented yet.
- Text over a glissando wavy line collided with line.
- The wavy line occasionally collided with final note and was not always centred within the two notes.
Fixed in Glissando::draw() by:
- linking text vert. offset to line type
- always rounding down the number of wavy elements and positioning the line according to the number of actual elements
