There are some inconsistencies in the current management of bar line `_generated` flag and user-modified type:
- Bar lines created by the New Score Wizard are flagged as non-generated, as well as bar lines of measures manually **appended** by the user, while bar lines of measures **inserted** are flagged as generated.
- If a generated bar line is individually changed of typed, it remains flagged as generated, it is not saved and the change is lost upon saving and re-loading.
- The management of the internal flag `BarLine::_customSubtype` is not always consistent.
- The `Measure::_endBarLineGenerated` flag was not always restored properly by undo.
This PR introduces the following fixes:
- The `_generated` flag is consistently used for bar lines whose type can be reconstructed from the context and then do not need to be saved to the output file.
- Normal bar lines are **always** created as generated: initially created by the Wizard, manually appended or inserted.
- Bar lines with custom type (i.e. different from the type which can be expected according to the bar line context) are always flagged as non-generated, ensuring the custom type is written to the output file.
- The `Measure::_endBarLineGenerated` flag is stored by `ChangeEndBarLineType()` and restore upon undo.
- Some test reference scores, based on the inconsistent bar line `_generated` flag, have been uniformed.
Notes:
- Tests about measure (and then bar line) appending, inserting and relative undo's are already included in the `tst_parts` test suite.
- Some inconsistencies remain in the management of custom bar line span and of system-initial bar lines: for the sake of simplicity, they will be dealt with in separate PR's.
When editing is exited, an (extra?) final call to BarLine::endEditDrag() is made **after** the last drag: it was finding shiftDrag turned off by the last call and forced the bar line extrema to coarse precision.
See http://musescore.org/en/node/22917#comment-99269
Fixes:
- resetting shiftDrag moved from endEditDrag() to endEdit();
- added a test at the beginning of endEditDrag() skipping it, if there is no drag.
Also fixed:
- a test for shiftDrag swapped with !shiftDrag
- an assumption that staves always have 5 lines.
Fixed by analyzing brackets and bar line spans rather than only relying on start and stop staff Y offset (which is not set if the staff is not shown).
Note: there are still issues with measure numbers, but these belong more to system items than to bar lining.
SMuFL distinguishes between the augmentation dot and the repeat dot (used in repeat bar lines).
This patch:
- adds the MScore font a separate glyph for repeat dot. The glyph is encoded in the same code point used by SMuFL and is currently a simple reference to the augmentation dot.
- changes the BarLine class draw code to use this glyph instead of the augmentation dot.
Bar lines belonging to a single staff are shown/hidden according to the staff type setting.
Bar lines spanning several staves are shown/hidden according to the setting of the staff type of the first spanned staff.
System bar lines (bar lines at the beginning of a system) are NOT hidden, regardless of the setting.