UI changes for text properties/styles in Inspector
OS: macOS High Sierra (10.13), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 78d0ea2
In current master, the Text Properties and Text Styles dialogs have been removed, and everything is centralized in the Inspector. This is part of a broader design ethos that I wholeheartedly support, involving both #118086: Eliminate most "Properties" dialogs in favor of Inspector for MuseScore 3 and, on the back end, the building of a correspondence between individual elements' properties (in the Inspector) and the global style (in Format / General Style... [which incidentally should probably be renamed since "General" is not needed to distinguish it from the now-eliminated "Text Styles"]).
While there remains a lot unfinished in both of those areas, and there are plenty of bugs to be fixed, Werner's overall vision has already begun to take shape, as is particularly noticeable when one seeks to edit the properties or style of a text element:
Setting aside bugs, there are a few things about this UI that could easily be made more user-friendly.
1) The two disabled (grayed-out) buttons to the right of each setting become enabled when that property is changed from its global style. The button with the counter-clockwise arrow sets the value of the property to that of the style. The other one, with the arrow pointing down, reveals an additional button that will set the value of the style to that of the property. "Set as style" should not be hidden beneath a dropdown; instead, it should be a button equal to "Reset to style" (or, perhaps, the two could be a single divided button).
2) In addition to controlling each parameter independently, there is single large "Reset Text to Style" button that handles all of them at once. As with the individual settings, there should also be a single large "Set As Style" button.
3) The order of the sections in the Inspector is off. Below the section with all the individual properties, there is one with a heading naming what kind of text it is, a menu to assign a style to it (changing all of the individual properties), and a choice of whether to place it above or below the staff. This entire section should be moved above the "Text" section.
4) While at it, the "Substyle" label should be simply "Style"—"substyle" is a term used in the code to help the developers distinguish the new system from the "text styles" that it replaced, but this is not relevant for the user.
5) The gray-green color used to indicate that a property matches its style is unusual, unappealing, and foreign to MuseScore, where aspects of the UI are generally blue.
Comments
Regarding #3, there is a certain hierarchy to the way the sections are ordered. The way it currently appears (Element->Text->Staff Text) is indeed correct.
For now, I'll list this here, although it's more than a UI suggestion.
The one bit of 2.x functionality that still seemed missing to me at first is the ability to make the default position of the element part of the style. However, I see this is now provided more at the element level than the text style level, via Style / General. Logically, this actually makes sense, and as it was we already had settings for lyrics and chord symbols there, so sure, why not. But for instance, I often used a custom text style for "alternate chord symbols" that I made smaller and higher than standard. Not sure the best way to do that currently.
relates to #274270: [EPIC] Text Styles issues
1 yes "set as style" should be a button. When i added it it was not clear this will be the only function. Also i believe "reset" is much more often used than "set as style". So i made it a bit harder to use to avoid pressing it by accident.
2 "reset text to style" does not reset all properties to style values. It replaces a text which may contain different fonts, sizes, color etc. with a simplified text with styled font, font size and font properties.
4 i changed "General Style" to "Style" and "Substyle" to simple "Style"
5 for the dark theme i used yellow which looks ok for my taste; any concrete suggestions for the light theme? (blue is already used for selection for radio boxes)
In reply to For now, I'll list this here… by Marc Sabatella
I am just in the process of adding properties for chord symbols to the inspector. Its easy to add special chord symbol substyles (named StyleA, StyleB or whatever) so you then can use two different chord styles in one score. I will implement it in this pragmatic way. Allowing arbitray user defined styles for arbitrary element types could be implemented but is much more complicated and expensive.
That sound like a good approach, but there would still need to be a way to set position as part of the substyle in order for this to work. It's not about collision avoidance - when one uses alternate chord symbols in the way I am talking about, they are normally written smaller and higher than the main chord symbols, even if there is no main chord symbol on the same beat. For example:
Collision avoidance could potentially handle the positioning of the Emi7, but not the A7.
I use this as an example of one reason why it could be useful to bring position back into the text style, but actually, there is a different, simpler, and perhaps better way to handle this particular case. What if, after entering a chord symbol and then hitting Space to enter the next chord symbol, it automatically inherited both the substyle and vertical offset of the previous chord symbol? Then you could just set up one alternate chord symbol the way you like - using a substyle to make it smaller, a regular position adjustment to move it higher - and then keep hitting Space to enter more chord symbols with the same substyle and offset.
I have often thought the same approach could be useful with lyrics. Maybe less important in master with the automatic placement, but it would have come in handy many times using 2.x. This much is probably a two-line change, and if adding offset to style seems too much, maybe this would do for the most common cases where it might matter.
Still, I could see people wanting to have two different substyles for staff text or other text types and wish them to have different offsets.
Current master implements an y offset value for chord symbol style and alternate style. Also every chord symbol now has an y offset property initialized by the style offset. This allows moving chord symbols with "autoplace" switched on.
Sounds interesting, looking forward to trying it out!
1) and 2) came up again at https://musescore.org/en/node/276360#comment-853431. I think it's very important to change these before the beta release.
This issue must be addressed in Beta to give users better UI/UX.
Relates to #278023: Style dialog usability issues for text somehow
Some of this is already improved, and my PR https://github.com/musescore/MuseScore/pull/4159 for #278023: Style dialog usability issues for text also generally improvses things. Here's my take on the rest:
Point 1 - there are now "S" buttons instead of dropdowns for some of the text properties (face, size, underline) but not the rest.
Point 2 here also relates to #278330: "Reset text to Style" doesn't work for all text types, and see Werner's comment above in https://musescore.org/en/node/274259#comment-844102. It sounds like this is by design currently - that is, the button is not intended to revert the settings in the Inspector to the current style defaults, but rather to remove any embedded formatting applied to the text via the toolbar (eg, superscripting or bold face applied to just some characters within the text) thus making the entire text consistent with the settings currently selected in the Inspector. These are actually both useful things, would be nice to have buttons for both. Plus a global "set as style" as mentioned originally.
Point 3 - I agree with Matt, order is surprising at first but actually makes sense in hindsight.
Point 4 - already fixed
Point 5 - no opinion on this
I will take a look at #1 at least as part of my crusade for consistency :-)
Hmm, regarding the "reset to default" & "set as style" buttons, I'm thinking about Isaac's original suggestion "perhaps, the two could be a single divided button" and also Werner's remark that he "made [the set as style button] a bit harder to use to avoid pressing it by accident".
Maybe instead of a button plus a popup menu or it was originally, or two separate buttons as it is now (for font face, size, and underline), what if we simply replaced the existing reset button with a button that pops up a menu with both of these options, "reset to default" the first choice? This declutters the GUI a bit over the original version (reset button plus popup), by even more over the current version (two separate buttons).
I should mention that these buttons are used not just for text styles, but all properties in the Inspector. If it can be reset, it gets a reset action; if it is controlled by a style setting, it gets a set as style action.
Here's a picture of an implementation.
Instead of the reset button plus down arrow, or reset plus "S", now it's just a single button with the down arrow (or we could use a "..." label). "Most" of the settings have both a reset to default and a set as style option in this popup menu. The ones that don't have a set as style could either use the same button for consistency even though there would be only one item in it, or they could have the dedicated reset button. It's only a few lines of code in inspectorBase.cpp to implement it all either way.
I am looking again at the chord symbols, and while I see separate text styles "Chord Symbol A" and "Chord Symbol B" (we may want to rename these, btw, in case people think "A" and "B" are specific chords), I still don't see a way to have different Y offsets for these styles, which is actually one of the most important thing one would want to have different (for me, all other settings except size would likely be the same).
Looks like the problem is that we don't actually have separate Y offsets available for chord symbol A & B - both actually map to chordSymbolPosAbove. If I'm right, I can fix this by adding those style settings individually, although I'm not sure how the automatic placement will affect this.
BTW, if nothing else, Select / More / Same subtype would be a way to move the B's after the fact, but Select / More seems broken right now with respect to text subtypes - it always selects everything.
Looks like this approach could work, but I'm not sure the best way to go about it, so I'll wait for Werner to weigh in.
Separate offset values for chord symbol styles a/b are now implemented.
Excellent, building now to test, but the code changes look like what I'd expect. BTW, two chord symbols on the same beat currently overlap at first, that's because of #278862: Chord symbol collisions not handled well. It fixes itself on the next edit, although it's finicky.
I think I want to get some forum feedback on best defaults for these styles. 18pt doesn't make sense for B size, should be same size or smaller I think, possibly italic. I'm also concerned about the centered alignment on both. It's right if there are fretboard diagrams but not otherwise. I changed it to left aligned in the jazz templates, maybe that's good enough. Again, though, probably best to get feedback from others here.
Meanwhile, I see there are not the "set as style" buttons across the board, so we can check that item off the list in this issue as well.
I've seen some other unexpected behaviors with text styles, mostly with regard to the Format / Style as opposed to the Inspector. Maybe it's time we close this issue, as I think everything discussed here is now addressed? I guess there are still some concerns over the color, but maybe that's best just having a separate P3 / S4 or S5 issue for. We could also have a separate S5 issue for the addition of global "reset to defaults" and "set as style" options, although I'm actually ambivalent about that. I don't know that it would be plainly obvious which settings this should apply to and which it shouldn't (ie, just the setting in the "text" section probably, but would people realize that?)
I am testing the chord symbol height settings and they do seem to work, but it's a bit erratic. I think it's probably because of the general autoplace issues with chord symbols (#278862: Chord symbol collisions not handled well), so maybe when that is resolved I can test more thoroughly.