Order of Text styles in Inspector dropdown and Styles dialog is different

• Dec 5, 2020 - 16:14
Reported version
Graphical (UI)
S4 - Minor

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit):, revision: 465e7b6

For some reason the text styles in the Inspector dropdown list are in a different order to those in the Styles dialog. Shouldn't they be in the same order?


Type Functional Graphical (UI)

Probably so. As I recall, it's deliberate the list isn't identical - we deliberately skip some in the Inspector that we think aren't relevant. I forget if they started out more in sync; I don't actually see any changes to the order of either list since they were separated out. See #278023: Style dialog usability issues for text for some background.

Hmm, in libmscore/style.cpp there are two arrays for those, with different orderings, static constexpr std::array<TextStyleName, int(Tid::TEXT_STYLES)> textStyles which matches the order in the style dialog (and has theur translatable names and Tids) and static const std::vector<Tid> _primaryTextStyles, which matches the order in Inspector (and only has the `Tid values).
The latter is also a smaller set than the former.


Inspector Edit Style
inspector.png textstyles.png

Oops, missed some... next attempt later today

Some arguments against alpabetical order:

  • Title should come before Substitle, and both before Composer and Lyricist.
  • Lyrics Odd Lines should become before Lyrics even lines (as verse 1 is odd, verse 2 is even)
  • Certainly some more of those
  • Finger memory: always being able to use e.g. the 3rd from top without reading and thinking which translatation you're using currently
  • Documentation and Support, (see above)

Same arguments that has been used for Palettes not being sorted in aplhabetical order.

I agree with you Jojo concerning translations. I sometimes rely on the order in translations to match up the different languages if I'm not too familiar with the language. I also agree that there is logic in putting title before subtitle as well as a few others that have a logical order. The order of the styles is not simply random but some thought has gone into them. Alphabetical order in almost any language would appear to be more random.

I agree alphabetic is not desirable. Not for this list, not for menus, not for palettes. Logic beats alphabetic any day. Or would you be happier if I wrote, "alphabetic any beats day logic"? :-)

But I strongly argue in favor of keeping the Inspector order as a starting point It was designed to be logical - keeping related styles together, to facilitate making the changes you'd actually be likely to make. The Style dialog menu is just completely haphazard, the result wen different styles happened to be added.

The basic idea in the Inspector list is the "page" oriented styles are grouped at the top, followed by the "measure" and "note" oriented styles. But there are definitely some inconsistencies. Instrument Name (Part) probably belongs with the page-oriented styles. Probably there could be some grouping of things like system, tempo, rehearsal mark, and repeat texts separate from things like staff, lyrics, and chord symbols. Sticking probably is better placed closer to staff text.

Look at the command palette of Visual Studio Code: they use logic: all "debug" commands are together, all "git" commands are together, all "file" commands are together.
But using logic doesn't mean throwing away power of alphabetical order.
1) categories are sorted alphabetically:
"debug" is before "file", and "file" is before "git"
2) items in one category are easy to find because, again, alphabetically sorted.
"debug attach" is before "debug clear", and "debug clear" is before "debug disable"

Please either propose an order for both or submit a PR yourself ;-)

Not sure what order to take, a) the Inspector one is not optimal so needs mending, b) the Edit Style on is longer, where to place the additional one?

IMHO we'd need to come up with a good logical order for Edit Style first, then adjust the one in Inspector

Agreed we should look at the full Style dialog list first, get the right order there, then the Inspector list can just the relevant subset. This doesn't bother me enough to want to submit a PR myself, but I do want to make sure we don't take a step backwards in terms of usability just to gain consistency. The current Inspector order is "pretty good" already; making it match the Style dialog list would be a regression to me.

So I'm fine with leaving it alone until MuseScore 4. Especially because any change at all is going to be off-putting to people who have become accustomed to the currently order. But, if someone were to make a change, I'd take the Inspector as a starting point, but tweak it to be that much logical.

Here's one cut at it:

(Page-oriented styles)
Instrument Name (Part)
Instrument Name (Long)
Instrument Name (Short)
Instrument Change [admittedly not really page, but keeping it with other instrument labels maybe makes sense too[

(Measure-oriented styles)
Measure Number
Multi-Measure Rest Range

(System-level styles)
Metronome [obsolete?]
Repeat Text Left
Repeat Text Right
Rehearsal Mark

(Staff-oriented styles)
Lyrics Odd Lines
Lyrics Even Lines
Chord Symbol
Chord Symbol (Alternate)
Roman Numeral Analysis
Nashville Number

(Note-oriented styles)
LH Guitar Fingering
RH Guitar Fingering
String Number

(Line-oriented styles)
Text Line
Hairpin [or, group with Dynamics, as we do in Inspector currently]
Let Ring
Palm Mute

Plenty of room for debate here, of course.

I like that you ended system-level with system text then started staff-level with staff text, they belong next to each other. I think sticking is a note text lie fingering rather than a measure text. Other than that I think there's sufficient logic to the list.

Thanks, that was a quite deliberate choice for system / staff :-). I tried to find a way to do the same with Dynamics and Hairpin or the various Instrument elements, but couldn't find a way to do it that I liked.

Implementation-wise, sticking is not per note, although personally I think it should have been. As it is, it is an annotation on the segment, just like staff text. But, logically it's similar indeed to fingering, so I did try to get them close. Tuplet could reasonably be moved after the rest of the fingering to make this work better. Or just move sticking after tuplet.

Fix version