Resolves: https://musescore.org/en/node/291957.
The mixer needs to be able to shrink in order to accomodate the piano keyboard if it is made visible. Decreasing the minimum height for the QScrollArea that contains the mixer sliders allows this to happen.
We have optimized the screenreader feedback when navigating
to only mention measure and staff if it has changed.
Blind users can easily lose track of where they are, however,
so this adds a new command "Get Location" that forces a full read.
It also re-establishes a lost selection (the last-selected note or rest),
which can also be useful for sighted users,
although Alt+Left/Right already re-established the location before beginning navigation.
Eventually I would like the new "Get Location" command
to read the current key and time signature.
Right now, though, it is is not straightforward to force the screenreader to do this,
I left it as a TODO in the code.
Resolves: https://musescore.org/en/node/298115.
This makes sure that ScoreView::startNoteEntry() clears the accidental state. Since this function already properly sets the duration and rest states, none of this needs to happen directly from within ScoreView::cmd().
Resolves: https://musescore.org/en/node/298121.
In addition to making the "Add Interval" commands apply the highlighted accidental when in note input mode, I have corrected a few cases where I had chosen the wrong tpc to use to calculate the AccidentalType for a user accidental, given the current value of styleB(Sid::concertPitch).
- Update and re-enable tests for QML-based plugins
- Remove mtest-specific #define's in plugins API code
- Make midimapping test compile
- Convert mtest/test.mscx to MuseScore 3 file format
- Remove unused files in mtest/
- Don't pass staff number to adjustCanvasPosition if trying to
adjust viewport to a frame. This avoids a crash itself.
- Implement a more robust approach to determine a measure relevant
to the current edit operation in CmdState. This avoids trying to
unnecessarily jump to the frame at the end of a score.
The reimplementation of scaling for the old palettes works
by scalingreferences to extraMag and grid size.
I do this on the fly, when drawing the palette, working with position,
and when calculating absolute sizes.
But the main data structure continues to store the mag & grid
is in "logical" units, so no additional scaling needs to be done
on read/write.
This is more along the lines of how the QML palettes are handled,
except that code is much simpler because it all gets funneled
through a single function.
MuseScore 2 used to scale the palettes according to screen resolution,
so they were the same physical size on all systems.
This was broken in MuseScore 3 development, so palettes are too small
on high DPI systems and too large on low DPI systems.
This fixes the issue by reinstating the code in palette.cpp
that scales the grid and mag by the global guiScaling setting
(same setting used to scale the score view itself).
That only affects places int he code where the "old" palettes
are still used - keysig and timedig dialogs, etc.
Similar but much code accomploishes the same in palettemodel.cpp
for the "new" palettes.
In addition, because users may *prefer* larger or smaller palettes,
I added an advanced preference to specify global palette scaling
(applied on top of the automatic DPI scaling).
This value is factored in to the main palette scaling.
In a corrupted score tick values may sometimes be not synchronized
between master score and parts. This may lead to incorrect setting
of layoutAll flag as ticks from different scores are compared.
Ensuring that only master score ticks are compared fixes layoutAll
flag for scores corrupted that way and prevents a crash due to not
making a full layout on score loading. This change makes no
difference for correctly saved scores.
