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
closed
Regression
No
Workaround
No
Project
MuseScore

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

• Feb 25, 2020 - 00:02

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:".

Reply

• Feb 25, 2020 - 03:52

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.

Reply

• Feb 25, 2020 - 13:04

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.

Reply

• Feb 25, 2020 - 18:54

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.

Reply

• May 2, 2020 - 23:51
Status PR created ⇒ fixed

Fixed in branch master, commit 6286d64ce0

_fix #301584: test for duplicates names in palette

adds a test for checking if there are duplicate
names in the palettes in the default workspaces
and manually removed the duplicate items by making
the names more descriptive._

Reply

• May 19, 2020 - 21:41

if I'm understanding correctly, these really are the same element, just presented in two different places for convenience (because no matter which place we put them, half of users look in the other place). Not sure how palette search & screenreaders should present these, but it wouldn't be lying if it said they were the same.

FWIW, I have a custom "Layout" palette with duplicates of the breaks, spacers, frames, staff type change, repeats, etc. I am not worried about the duplication myself and don't need it disambiguated. Hopefully any fix provided here doesn't make this work less well than it does now.

Not sure if there are any other true duplicates. The parentheses on the noteheads and accidentals palette, maybe?

Reply

• May 19, 2020 - 22:21

Possible solutions in (my) order of preference:

  1. Detect that the actual element is the same and only then allow the names to be the same.
  2. Allow names to be duplicated in different palettes, but never in the same palette.
  3. Have an exceptions list to say that certain names can be repeated.

Reply

• May 19, 2020 - 23:57

I don't understand 3), what would happen if I added something to my custom palette that wasn't on your list? As long as the answer is, it continues to work without a hitch as it does currently, that's fine. A dialog that pops up and says "sorry, you can't make a copy of this palette element because it isn't approved" would not be acceptable, nor would silently rejecting the attempt to make the copy. But either making the copy and keeping the name the same, or making the copy and making a change to it along the way is fine. Although if a change is made, it would be nice if somehow it could be just to the internal cell name and not to the tooltip.

Reply

• May 20, 2020 - 01:10

@Marc Sabatella, we are talking about a compile-time check in mtest that fails the build if there are palette items with duplicate names defined in the default Basic or Advanced palettes. Naturally you can call items whatever you like once MuseScore is running.

Reply

• May 20, 2020 - 04:38

Ah, I see, sorry for the noise then!

In that case, any of the above seem fine to me, but 1 doesn't seem feasible, in part because of the observation about staff line on vs off, but also it just seems any solution devised is likely to be hacky and fragile. Maybe I'm wrong here too though...

Reply

Fix version
3.5.0