Palettes: give all elements unique names

• Feb 24, 2020 - 21:12
Reported version
3.x-dev
Type
Ergonomical (UX)
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
PR created
Regression
No
Workaround
No
Project

Some palette elements that a visually different have the same name. This affects tooltip text and accessibility information set to screen readers.

Examples of duplicates:

  • "Line"
    • used for a basic horizontal line in the Lines palette
    • also a type of vertical staff bracket in the Brackets palette
  • "Pedal"
    • Used multiple times in the Lines palette.
  • "Arpeggio" and "Glissando"
    • Both used multiple times in the Arpeggios and Glissando's palette.
  • "Tempo text"
    • Used for all elements in the Tempo palette (i.e. the contents of the tempo text is not included in the name).

There should probably be an automated test to look for duplicates. Note that Qt has a match() function that could be used to search the palette model for element names. You would throw an error if it returns more than one match for each name.


Comments

On the same subject: a quite useful optimization could be to add a prefix a palette-specific prefix to each of the cell names, so for example the dynamics would be "d:pp", "d:p", "d:mp", etc.

Or - a more "codey" way - perhaps add the prefix code to the palette itself, and have the search code allow searches of that form "prefix:cell" by parsing the search string. The advantage being the palette cells could remain simple for the screen reader. Although if the first approach were chosen with the hard coded prefixes in the cell names, the screen reader code could simply strip off the prefix.

Either way, this would yield a quick way to access, for example, all dynamics: "F9 d:".

Good idea, though I think it merits its own discussion outside of this issue. I might prefer a suffix (e.g. "pp dynamic") rather than a prefix, or I might want to have a suffix for speech and a prefix for searching, for example.

Let's keep the current issue about avoiding duplicates, as that is an ideal candidate for a prospective GSoC student to fix. It's relatively straightforward, yet it allows them to get some experience with the palettes, model-view programming, and potentially mtest as well.

Not a project. Potential students are expected to submit a pull request before they send us their proposal. This shows us that they know how to build MuseScore and use Git, etc.

True, what I'm describing is more involved and best considered separately. FWIW, I forgot that search doesn't require an initial substring match, so yeah, suffix works too.