Resolves: https://musescore.org/en/node/301496
Alt+Left/Right commands were skipping voltas because
we were checking start element and checking against the active staff,
but the start element is actually the measure for voltas.
The main change here is to go ahead and visit the volta
if the active staff if you are navigating the top staff.
Arguably, it could make sense to check for the top *visible* staff,
since that is what the volta at least appears to be attached to.
So I have code here to that.
But I disabled it because in practice,
neither the navigation commands themsevles nor the screen reader
treat invisible staves specially.
So a blind user navigating would have no way of knowing
the top staff is not visible.
So they would likely continue to see it as relevant.
I would not the same issue occurs for system text,
which we always treat as attached to the top staff only.
I added a TODO to indicate where this code would need updating.
Eventually we could consider coming up with some way
of presenting information about hidden staves.
Perhaps in conjunction with a facility allow user
to hide staves on specific systems only,
which seems to be a fairly common request.
Resolves: https://musescore.org/en/node/301436
The accessibility navigation commands
(Alt+Left/Right, also Ctrl+Alt+Shift+Left/Right)
were not properly checking for mmrests,
resulting in selection of elements in the underlying measures
that were not valid in the current layout.
This adds the necessary checks.
Mostly just a matter of adding "MM" to various function calls.
In a couple of places, the appropriate function did not exist,
so I added it.
Also corrected errors in Ctrl+Alt+Shift+Left/Right
that occurs when going past the end of a staff,
the code to wrap around to the next staff this case well.
In part this is because the implementation of barlines changed
since the code was written.
Barlines are per-staff now even when spanned,
so the use and management of prevTrack is no longer appropriate.
There are a number of cases where next element ended up hitting unexpected code paths.
Mostly these involve cases of elements being attached somewhere pther than expected:
symbols attached to rests or to other symbols rather than to notes,
chord symbols attached to fret diagrams.
This change addresses these cases in a few different ways:
1) for symbols to attached to other symbols, or chord symbols attached to fret diagrams,
srt the track correctly (it was -1, causing the the code to not be able to find a next element).
2) for symbols attached to rests, be sure to handle that case in Score::nextElement(),
and also make sure that Segment::nextElement() and Segment::prevElement()
don't assume these elements actually have the segment as parent,
but instead check for that and move on if not.
Blind users find it disorienting for the previous element command to wrap to the end,
or for next element to wrap back to the beginning.
Besides, no other navigation commands work that way.
This commit stops that behavior by simply swapping the calls
to Score::lastElement() and Score::firstElement() in the places where this wrapping occurs.
That is, if previous-element finds no previous element,
we return the first element.
Added code to read the text within frames in accessibleExtraInfo(),
but also fixed the navigation to check for a frame
before moving to the next/previous measure.
Because frames will generally have a track of -1,
I also needed to take advantage of the tracking of the current track from a previous commit
so that nagivation continues on the correct track after passing through a frame.
I also needed to be careful to handle the -1.
- tick names a position on the time axis
- tick is always a Fraction()
- only Measure() and Segment() (and Tuplet?) have a tick value
- tick() for an generic element return only a sensible value if isMeasure() or isSegment() or isSegment(parent())
- "ticks" names a duration stored in a Fraction()
- the tick value for an Segment is relative to its measure
- rename "duration" to "ticks"
- rename afrac() to tick()
- rename rfrac() to rtick()
- rename some variables, changing "fraction" into "tick"
(example: actualFraction() into actualTicks())
- Lyrics ticks are written as Fraction, on read if xmlreader sees a "/" it reads a fraction
else midi ticks for backwards compatibility
__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.
