In old scores (1.x and transitional 2.0 scores, including templates and "My First Score"), regular bar lines are often needlessly stored in score files.
These bar lines are read back as non-generated, and may misbehave; for instance, may generate an extra 'courtesy' start-repeat at system end, if an start-repeat is added at the first measure of next system.
This fix normalizes bar line flags if, while reading them back, they are found to be normal.
Note: only a single line of code is changed in Measure::read() methods; the large number of affected files is due to test fixing.
In some engraving styles (mainly jazz), a double system initial bar line is used at structural articulations of the piece.
The PR supports this style, by adding a `_systemInitialBarLineStyle` variable to the `Measure` class which controls the style of the system bar line when the measure is the first of the system and by default it is set to NORMAL. This variable is not accessed directly; rather it is controlled by manipulating the system bar line. A system bar line can be edited:
- by dropping on it a bar line style from the palette (structural styles, like any repeat or END are ignored);
- by selecting it and double clicking a bar line style from the palette (same note as above).
It can be reset:
- by undo;
- by dropping on it (or selecting and double clicking) a NORMAL bar line style from the palette;
- by selecting and deleting it.
As the system bar line style is stored in the measure, if the first measure of a system changes (because of some other editing), the system bar line style will follow accordingly.
This PR should complete the revision of bar line flag managements.
- Make sure single bar line span changes affect both the `_customSpan` and the `_generated` flags.
- Make sure that manually bringing a custom-spanned bar line to default span resets the `_customSpan` flag and, if no other customization is in effect. the `_generated` flag.
- Deleting a measure bar line resets it to default configuration.
- Fix a missing initialization of `Measure::_endBarLineColor` variable.
- To simplify tests and debug, check boxes for the `BarLine::_customSpan` and the `BarLine::_customSubtype` have been added to the debugger dialogue box.
As far as system-initial bar lines are concerned, they were made un-editable by a recent commit (https://github.com/musescore/MuseScore/pull/1300). This PR add a few consistency changes:
- system-initial bar lines do not accept drops;
- they are not saved to score output files and are ignored when reading from them;
- their internal `_customSybtype` and _customSpan` flags are always false;
- they do not show up in the Inspector (if a system bar line is selected, the Inspector remains blank)
This PR DOES NOT include the special system-initial double bar management recently discussed. This will be part of a specific PR in the next days.
Together with previous PR's, this should ensure that:
- bar lines are written to a score output file only when some customization is in effect which cannot be reconstructed when reading back;
- any measure bar line can be edited;
- any measure bar line user edit is saved, written to the score file and read back properly;
- no system bar line edit is possible.
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.
If a measure has, in one staff, a bar line with a custom sub-type, the sub-type is applied to the bar lines of all the staves of this measure.
Fixed in `Measure::read()`.
not there yet, as at least overloaded operators for |, &, |=, &= and ~ would be needed to make this fully working. And even then it'd require lots of explict casting. This is most probably not be worth the price...
and change to a better sentinel for end of list.
Also move the Q_DECLARE_METATYPE(Ms::ValueType) nearer to its
definition.
This should conclude the work on the enums in libmsore/mscore.h.
