This commit removes some -Wempty-body, -Wmaybe-uninitialized, -Wunused-variable, and -Wstrict-overflow compiler warnings that arise on my x86-64 and ARM arch linux machines when compiling release.
These compiler warnings don't seem to cause any bugs, but since they pollute the build output, they make it harder to spot potentially important warnings that might arise, so I'm making these small changes to keep the build output clean.
The "empty-body" warnings occur because the Q_ASSERT statements are removed for release compiles, causing the else blocks to be empty. Surrounding the Q_ASSERT with brackets will let the compiler know we aren't unintentionally having an empty else body.
The "maybe-uninitialized" warnings are handled by assigning the variables to 0 either at initialization or in a switch default block.
The "unused-variable" warning is due to PeriodItem updatePeriods[] in preferences.cpp being defined but never used, so I've removed PeriodItem. Also a recent commit has an unused "int staves", which I've removed.
The "strict-overflow" warning is due to compiler wanting to perform an optimization which would cause signed overflow during a comparison operation. I've made the compiler happy by casting the barIndex'es into unsigned ints, so it doesn't have to worry.
This patch gives better control on lyrics dash management and it is intended to supersede https://github.com/musescore/MuseScore/pull/2213 which did not suit the taste of several forum users; for a discussion, see https://musescore.org/en/node/76021 .
Adds 3 new score style parameters:
- `lyricsDashMinLength` to control the minimum dash length (default: 0.4sp)
- `lyricsDashMaxLength` to control the maximum dash length (default: 0.8sp)
- `lyricsDashForce`: if set to __true__, a dash is always generated between two syllables of a word and, if there is not enough space for the min dash length, more space is added between the syllables to accommodate it; if set to __false__, no extra space is added and the two syllables are joined together (default: true)
The effect of the last parameter is exemplified by the following screen-shots:
Current situation (before this patch); if there is no room for the min dash length, the dash is skipped and some blank is left between syllables:
Patch with `lyricsDashForce = true`; chords are further spaced and a min-length dash is inserted:
Patch with `lyricsDashForce = false`: the second syllable is moved (slightly) to the left to reclaim the blank:
If a section break occurs on a non-measure MeasureBase object such as a vertical or horizontal frame, then the courtesy key or time signature should still not be displayed in the final actual measure of the section.
__Background__:
In the original TAB implementation, the "Stems above / below" setting was followed when there was only one voice, while with multiple voices, voice 1 stems were always above and voice 2 stems always below.
In issue https://musescore.org/en/node/63561 the OP reported that:
- with multiple voices, stems in TAB did not follow the "Stems above / below" setting;
- extra space was allocated for voice 2 stems.
Both issues were more apparent than real, because the example provided casually had no stems in voice 2 (all whole notes). With the commit 33797cd6c5 :
- voice 1 stems are forced to be below or down according to the setting even for multi-voice cases and voice 2 stems on the opposite side;
- additional distance is allocated above the TAB staff (but not below) if stems are above or there are multiple voices or below (but not above) if stems are below and there is only voice 1.
__Issues__:
1a) The original stem directions were __by design__, assuming that with multiple voices notes of voice 1 tend to be above and notes of voice 2 tend to be below; then it is more sensible to put voice 1 stems above and voice 2 stems below, limiting the "Stems above / below" setting to the single voice case only.
1b) Stem direction controls slurs and tie placement and users are complaining that, with multiple voices, stems, slurs and ties are placed unexpectedly. See issue https://musescore.org/en/node/69846 and forum post https://musescore.org/en/node/69821 .
2) About additional staff distance allocation, with multiple voices it has to be allocated __both__ above and below, as stems may appear both above and below.
__Fix__:
1) This patch fixes 1) by restoring the original stem direction computation (single voice: follow "Stems above / below" setting | multiple voices: voice 1 unconditionally above and voice 2 below) when tab is configured to have stems beside the staff and also when it is configured to have __no stems at all_ (so that slurs and ties occur in expected positions).
2) It corrects additional staff distance allocation for the multiple voice case. No resources are spent to check the odd case when one voice casually has no stems over the entire system (in which case, additional distance on that side could in theory be spared).
