Style dialog usability issues for text
I've spent a fair amount of time playing with the text style facility, and while I think I've done a pretty good job of figuring out how it works, I am pretty mystified as to why on a lot of this, and I am hopeful we can improve this further before beta, or documenting and supporting it is going to be not fun.
I am reporting this as a bug although I fully accept there might be some rationale I am not understanding behind at least some of what I am describing. It's really a bunch of interrelated issues to me, but to me the whole problem stems from the way this gradually evolved over time as a set of solutions to specific problems rather than ever really stepping back and looking at the big picture. So hopefully now is the time. Refer also to the EPIC #274270: [EPIC] Text Styles issues, but what I am describing here is almost all new.
In general, I think the way text style information is distributed in the Style dialog is problematic. Some elements get their own top level settings for default placement and position above/below (eg, Staff Text, Rehearsal Marks), others have a subset of the usual text style settings combined with "general" settings for the element (Header, Footer, Measure Numbers, Tuplet, etc), and then there is a whole subsection Text Styles listing more elements with the usual controls there.
Even if we accept there might be a point to this, there still seems to be some duplication that doesn't make sense. Some elements like staff text are listed in both places, with different sets of controls (eg, only position in the main Staff Text section, a subset of those same position settings plus font info under Text Styles / Staff). In most of these cases the common fields seem linked - so for example setting Text Styles / Staff / Offset / Y will also update Staff Text / Position above, but only after hitting OK and then re-opening the dialog. However, Tempo Text does not seem linked - the settings under Tempo Text the Text Styles / Tempo are completely independent, and only the latter seem to actually be honored. If you use the Inspector to update the style, it updates the Text Styles / Tempo. But the Inspector doesn't give you the option to choose a different text style.
While some elements have settings duplicated, other elements are only found under their own main headings (eg, Lyrics), other are only found under Text Styles (Title, Repeat Text Left/Right).
BTW, the inability of the Inspector to select text styles also applies to Instrument Change. Here, there isn't even an Instrument Change text style listed anywhere in the Style dialog. For most other text elements, you can select the different text styles within the Inspector, but only the subset listed under Style / Text Styles are available - so for instance, no ability to set a staff text to Lyrics style, which is a fairly common thing to want to do. Functionality-wise, this seems the biggest oversight. Just about everything else I can think of people often wanting to do is possible, although the specifics of how to do it differ by element type.
Some text elements allow you to select alternate text styles but only within a narrow range, an these are not found anywhere within the Style dialog. Chord symbols allow you to select between "A" and "B" (I might prefer "Normal" and "Alternate", but whatever). Fingering allows you to select between the usual options. I can see why it might not make sense to allow random settings here, but again it seems oddly inconsistent, and now that we have User styles, I'd love to see those be options here.
That's about it, I guess. If I ignore the Styles dialog and pay attention only to the Inspector, as I had been doing until recently, the picture is not so bad - just the glitch with the missing "Style" field for tempo and instrument change, and the gripe about Lyrics being missing from the list of available styles. Well, also "Set as style" still needs to be made a button rather than a dropdown. But those are smaller concerns. It's once I really start digging into the Style dialog that I like what I see less and less.
Comments
I should also note that for elements not listed under Text Styles, some of them allow you to choose font under their own main heading (Lyrics, Tuplets, Measure Numbers, etc) but others don't (Ottava, Dynamics, Pedal, etc). For the latter, the only way to change the style setting is via the Inspector. That wouldn't be such a bad thing in itself if it didn't all seem so inconsistent.
The current state of the style editor is a bit inconsistent. The reason is that all changes to the style/property system are made in serveral iterations. The ui was only adapted to make it work again and to be able to test the implementation.
That certainly makes sense. Now that all (?) the functionality is in place, hopefully we can step back and spend a little time coming up with a good UI strategy.
One thought I had is that there is a difference between "regular" text elements that you attach directly to notes/rests - like staff or expression text, lyrics, tempo markings, rehearsal marks, etc - versus things like that are either generated by the program or contained within other elements, like measure numbers, tuplet numbers, headers and footers, text within voltas etc. So that is one "logical" basis for there being a difference in how the settings are organized.
Right now, the styles listed under Style / Text Styles mostly correspond to that first category, except there are a few things that seem missing (lyrics, chord symbols) and a few things that maybe don't quite fit in with the others (instrument name, header, footer) but don't hurt either. Having instrument name (part) here but instrument name (long/short) under System is another odd-seeming inconsistency that might make sense at an implementation level but probably doesn't for the user.
I also assume that the above/below placement settings are only valid for certain element types, so these probably need to be separated from the more universal text style settings. Same with the autoplace min distance settings.
Anyhow, I'm certainly not saying everything needs to be 100% consistent, just that it would be nice to have some logical basis for the differences, so that once one understands the concepts behind it, things make sense.
In the current implementation text styles are a collection of properties which are common to some element types. The 'text style' itself is a property for some elements. For this elements the text style can be changed. So the text style property allows to handle (change exchange) several styled properties at once with a name.
So there is a separation of properties for (text) elements: the collection of properties named 'text style' and properties for the special semantic of an specific element.
There is one functionality missing: the ability to create arbitrary user text styles and give them a name. The current workaround is to use "user1 user2 etc." styles.
Right, and there is a PR out there to allow renaming of those user styles, along with importing named custom styles from 2.x.
Meanwhile, I've also studied the code more to understand better. What I am seeing is that a "text style" exists in more or less form as it did before even if the implementation is very different - it is still a set of specific style settings (font face, size, alignment, frame, etc - 14 in all). And the Tid enum still names them all individually, and there are still as many of these as there always have been - a few more, actually (chord symbol a/b, the user styles). Offset is mapped to either position above or below as appropriate for the element.
However, for some of those styles, some of the 14 properties are really just mapped to a global default value - like, Dynamics doesn't have its own frame settings, glissando doesn't have its own alignment. There is only a subset of these styles that have a "full" set of values, and these are the ones available that are included in Format / Style / Text Style. The Inspector uses its own subset when allowing you to choose, but it's the same idea.
The Inspector is right now the one almost foolproof way to access all of these settings - anything that has a Text section allows you to edit those 14 properties. With the exception of offset, which is actually within the element section, hitting Set as Style for any of these properties makes the change to the currently selected style for the element. eg, if you've set a staff text to use Tempo style, Set as Style changes the Tempo style. But "Set as Style" for offset, being part of the element section, actually changes the staff text style even if the style for that element has been changed to Tempo. An interesting effect of how this is all implemented: the mapping of certain style settings to text defaults is honored here. So for instance, hitting "Set as Style" for the frame around dynamics actually affects all elements that inherit the default frame settings - that includes measure numbers, instrument change text, tuplets, etc.
Format / Style / Text Styles lists the same basic subset of text styles that are available to select in the drop down in the Inspector, and it allows you to change any of the 14 properties for those styles. The remaining styles have only their non-default-mapped settings available, via other sections of Format / Style.
Do I have this right? Based on this understanding, I think I can suggest enhancements to improve consistency without fundamentally changing things, and also come up with a strategy for documentation.
One basic question we can ask ourselves: is there a good reason for this mapping of certain settings to text defaults? In other words, is there that some elements have a full set of 14 text style settings, while others have only a few of these and map the rest to text defaults, so that for instance dynamics and tuplets share the same "frame" setting? I can sort of imagine if this was considered carefully, it could be a good thing, and in that case, the challenges are to make sure we do consider this carefully, and then expose this to the user this in a way that will make sense.
On the other hand, if the only reason we don't have all 14 settings available for all text styles was just to avoid the grunt work of defining them and then providing sections in the Format / Style for each text style individually, maybe it is time to revisit this? Now that we have Format / Style / Text Styles, it seems to me it would not take long to add the "missing" style settings and allow all of the text styles to be first class citizens as they are in 2.x. Seems to me this would greatly simplify how things appear to the user.
The "default" style is more or less a placeholder for missing or unused style values. My hope was to minimize the number of needed style values. But no property exposed in the UI should be mapped to the default style. Some of the properties make not much sense for certain elements (frame for lyrics?) but should not hurt. Its easier to keep them as removing them from the inspector.
OK, then I suggest we do go ahead and make all the text styles "full" - no more mapping of things to default, and all text styles then editable under Format / Style / Text Styles and selectable for any text element in the Inspector. However much we think it might not make sense to add a frame around a lyric, it's going to make less sense to try to document things as they are now, and I'll bet it's not long before someone requests the ability to add frames around lyrics anyhow.
We could also consider removing the current controls for lyrics text etc from Format / Style / Lyrics etc so the text controls are only in Format / Style / Text Styles, but the duplication doesn't actually hurt. Although since you can also update these styles in the Inspector, I do think having them scattered all throughout Format / Style is duplication we don't really need.
I think I'll go ahead and give this a shot myself. If it's straightforward I should have a PR within the next day or so, if not I'll post again.
Hmm, I see Werner has already gone and added a bunch of the missing style values. That was a lot of "grunt" work, but I really appreciate it, so thanks! FWIW I was toying with using macros to somehow automate the process a little, like "#define DECLARE_TEXT_STYLE(ts)" to generate the list of style values in Sid, etc. Not sure that would have been less work in the end.
I need to play with this some more, but am thinking I will still want to at least update the list of styles presented in the Inspector and in Format / Style / Text Styles. I think there is probably also some inconsistency regarding the "FontSpatiumDependent" and "OffsetType" fields, but I'm also not sure how important it to expose these at all.
By the way, the new "S" button for "set as style" is nice, but it's only there for some fields - most still have the dropdown.
I have submitted a PR that deals with most of the remaining GUI issues (now that Werner has done the heavy lifting):
https://github.com/musescore/MuseScore/pull/4159
Here is what it does:
Still to do - adding a control for text style to the inspector for tempo, dynamics and lyrics (or we could factor this and placement out into a new inspector section), also maybe removing the now-redundant controls from the various individual section of the style dialog for staff text, lyrics, etc. Also dealing with the offset type field (sp vs abs), probably should be added to Format / Style / Text Styles. Oh, and more "S" buttons to replace "Set as Style" dropdowns.
BTW, I could imagine someone complaining the list of available styles in the Inspector is too large. A valid concern. But I would say if we do want to arbitrarily restrict what is available, we should probably define an appropriate enum or iterator or whatever in style.cpp to define what that subset is, then it can be re-used elsewhere as desired.
I updated my PR to add the text style controls for tempo, dynamics, and lyrics. I tried to also add for repeat text, but there is a complication there since we don't actually set a default style (some are left, some are right) and it got a little messy. I also went ahead and defined a subset of the available text styles to select from for use in the Inspector, somewhat larger than the current set but not everything because the list appeared unnecessarily overwhelming. All text styles remain available in Format / Style / Text Styles.
I've also been experimenting with the "set to style" control, see #https://musescore.org/en/node/274259#comment-869840. But I wasn't planning on incorporating that change into this PR unless there was more widespread agreement.
Fixed in branch master, commit e43b41453e
fix #278023: add missing text styles
Fixed in branch master, commit b94e68f8be
Merge pull request #4159 from MarcSabatella/278023-text-style-usability
fix #278023: text style usability issues
Automatically closed -- issue fixed for 2 weeks with no activity.