- 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.
An attempt to improve the layout of grace notes after chord. It probably does not cover all the possible interactions with other score elements, particularly in tight scores, but it should achieve reasonable results for common cases with a rather simple algorithm.
For some discussion and examples, see the original issue at http://musescore.org/en/node/15022 and the forum thread at http://musescore.org/en/node/45346
In `Measure::layoutX()` and in `Score::computeMinWidth()` there is code to add room for dash padding in lyrics syllables, with a reference to `System::layoutLyrics()`.
As `System_layoutLLyrics()` no longer exists and as `LyricsLineSegment::layout()` now adjusts (and occasionally skips) dash width to actual note distance, this is now redundant and may in some cases interfere with the `LyricsLineSegment::layout()` calculations.
Some tests with rather dense polyphonic scores did show that some space may be gained, without raising any evident 'crowding' problem.
In small staves, some types of bar lines are drawn with small lines and some are not (mainly end bar lines). In addition all bar lines of a measure are left-aligned; when small and regular staves are mixed this looks untidy for mid-system bar lines and quite wrong for system-end bar lines. See http://musescore.org/en/node/44966 for a discussion and an example.
This patch tries to achieve the best-looking possible result:
- it lays out and draws all bar lines in small staves with small widths
- it right-aligns end bar lines, end-repeat bar lines and any bar line at system end
- it left-aligns start-repeat bar lines
- it centre-aligns any other bar line.
Implements melisma and dash lines for lyrics spanning several systems.
The melisma and dash line is based on the `SLine` class and its segments on the `LineSegment` class. Both the whole line and its segments are not selectable, marked as generated and not saved in the score file, which is not changed in any way.
For very wide dash segments, several dashes are drawn; the distance between the dashes is not configurable.
Lyrics layout code in `Measure` class and in `layout.cpp` file has been commented out as the lyrics line layout is all contained in the lyrics.cpp file
The line is registered with the `Score` (to have its layout delayed until all elements are positioned) with a mechanism similar to other `Spanner`'s, but in a different container (`_unmanagedSpanner`), as the owning `Lyrics` should decide when create, register, unregister and delete its line.
The line segments are registered with the `System` they belong to (to have them drawn), in the same way as other `Spanner`'s.
There is code for using the dash metrics of the lyrics font, but it is turned off via a conditional directive, as there does not seem to be a reliable way to determine the dash metrics; conventional values (determined by trials and errors and based on my taste!) are used when the conditional directive is off.