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.
* Found via `codespell -q 3 -S ./share/locale,./thirdparty -L ba,cann,clas,dur,foto,iff,nd,ois,ot,pres,possibile,snaped,strack,tage,te,uint,thru,valu`
* Some revisions made per feedback given during review.
* Follow-up typos for review
* Add revisions per feedback
Annotations are appended to the annotation list as they are entered.
This means they won't necessarily be sorted by track,
if you enter them onto staves in any order but top down.
The result is the navitgation code skips all annotations for a staff
after the first annotation it encounters on a different staff.
This commit fixes the issue by continuing to loop through the annotations,
looking for more on the same staff.
anatoly-os: rewrite the improvement from #5308 using `find_if`
anatoly-os: Did refactoring using `find_if` to make the code cleaner. Initial idea and implementation are authored by @MarcSabatella.
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.
This was reported original as a crash in fingering entry,
but the underlying problem is in navigation,
When we have run out of notes in the current segment on the current staff,
we should move on to the next segment,
but Segment:nextElementOfSegment() was erroneously finding a note or rest
in voice 4 of the last system.
That is because the loop through the tracks was not handling the end condition properly.
We find an element but don't check that it is on the right staff.
This change simply adds the missing check.
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.
The navigation code for next-element and previous-elements ignores measure elements
(elements in the el() list for the measure).
This change adds handling for this
by checking for measure elements before moving to the next or previous measure
in Segment::nextElement() and Segment::previousElement(),
There is corresponding code in Measure::nextElementStaff()
and in Measure::previousElementStaff()
to iterate through multiple elements if present.
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.
The navigation previously had special cases for accidentals and articulations
to bump up to the parent before proceeding, but this ignored fingerings.
The fix here generalizes the test to catch other elements with notes or rests as parents.
Also, since fermatas are now segment elements rather than articulations,
that test is moved to be with the other segment elements.
* Fix#289672: Reset '$STRING' value strings reference non-existent $STRING
* Fix#289957: wrong string in Advanced palette results in it not getting translated (ommission from #5016)
* Fix#272546: Baritone Oboe should be named Bass Oboe in English (see also #4474),
"Hautbois Baryton" in French, "Bariton Oboe" in German, "Oboe Bajo" in Spanish.
Plus:
* Add (back) units for sp and pt
* Clarify transposition settings in staff properties dialog
* Fix a reset button's accessibilty info to match the label
* Quote buttons/keys in tours
* Barré to Barre
* Fix capitalization (see also #5102)
* Don't translate debugger (which is not visible in RELEASE mode)
* Sforzato to Accent in shortcuts (see https://musescore.org/en/node/290297)
* Some whitespace and punctuation fixes
* Fixing some error messages
* Removing a redundant word
* Disambiguations for various occurences of "None" which may require different translatations.
* Simplify some strings with URLs for translators
* Don't translate scroipt recorder (which is not visible in RELEASE mode)
- 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
- Move Qml plugin engine out of libmscore
- Add Pid::TICK handling to Element class
- Make tick QML property correspond to absolute tick in all contexts
That is a temporary solution though, a proper solution would
require revising Pid::TICK handling
- Move plugins API to api directory
- Rename ElementW -> Element (PluginAPI namespace)
- Remove Qt meta-object macros from Score in libmscore
- Remove string-based access to properties from QML
- Remove unused functions from Note
- Rename QML properties names to camel case
Two reasons:
- They were named so in MuseScore 2.X.
- Using underscored_names is less consistent with MuseScore
coding style.
Melisma are not affected by this patch and still can cross barlines
Shapes change hack makes horizontal spacing apply only for the
specified spacing type even in case of zero-width shape. That way
chord symbols can cross barlines again.
