[MU4 Task] Expose text formatting options in Properties for all text lines

[bkunda]

Task description This design resolves #13338.

For all applicable text lines, we would expose the regular text formatting options in the Properties panel. These options would appear beneath the properties specific to the selected element.

This is an example of how it would appear beneath the Line object:

Text line objects to which this would apply:

• Volta lines
  • Prima volta
  • Seconda volta (open)
  • Seconda volta
  • Terza volta
• Ottava lines
  • 8va alta
  • 8va bassa
  • 15ma alta
  • 15ma bassa
  • 22ma alta
  • 22ma bassa
• Palm mute
• Let ring
• Text line
• System text line
• Staff text line
• Barré line
• Crescendo line
• Diminuendo line
• Line
• accel.
• allarg.
• rall.
• rit…
• calando
• lentando
• morendo
• precipitando
• smorz.
• sost…
• string.
• Straight glissando
• Wavy glissando

Thanks!

[Gravifer]

Related to this line

[cbjeukendrup]

Related to this line

I don't think that's true; that code is about MusicXML import, but this issue is purely a missing UI control in the Properties panel.

[cbjeukendrup]

@bkunda In MS3, it was possible to adjust the text style for each type of text individually ("start text", "text when continuing to a new system", and "end text"). That might be useful in some cases, especially for custom lines. I assume that in your design these options only control all three text types at once, right?

[bkunda]

@bkunda In MS3, it was possible to adjust the text style for each type of text individually ("start text", "text when continuing to a new system", and "end text"). That might be useful in some cases, especially for custom lines. I assume that in your design these options only control all three text types at once, right?

Yes that's right.

I can think of a way within the proposed design, whereby we could enable the ability to independently style text components across multiple systems; the solution would be to apply the styling only to the selected segment of the text line (it seems that each segment is independently selectable):

This could, however, become annoying for the (I suspect majority of) use cases where the user wants the one style to apply to their entire line across multiple systems – I.e. they would have to manually style each segment one system at a time. This nuisance could be mitigated though, if we permitted list selection (i.e. with ctrl/cmd), which would allow the user to style all selected text components across multiple systems at the same time.

At any rate, I am keen to avoid relying on the design pattern from 3.6, where multiple instances of the text style controls were always on display for both start and continuing text.

I have a sense that there are probably important use cases for styling continuing (and end) text differently to the start text, but would be keen for @oktophonie's opinion here.

[oktophonie]

Off the top of my head I can't think of any reason why you'd style start/continuation/end text differently, though I have no doubt that someone would be able to come up with one.

However, what I would like is a way of styling within the text. For example, one major publisher wants continuation styled as "(cresc)" (i.e. italic letters but non-italic parentheses) which I don't think is possible at the moment.

[bkunda]

However, what I would like is a way of styling within the text. For example, one major publisher wants continuation styled as "(cresc)" (i.e. italic letters but non-italic parentheses) which I don't think is possible at the moment.

I wonder if there is anything stopping us from being able to make the text component of a text line object editable on double-click (the same as our other text objects)? This way, you could double click on the "(cresc.)" continuing text, highlight the parentheses, and turn off the italics style in the text properties.

I can only think we may run into some problems with things like ottava lines, which use a <sym></sym> tag (wherein which I suspect some style settings are already defined??). But this isn't the case for cresc./dim. lines.

[cbjeukendrup]

Those <sym></sym> tags are special, because they insert the symbol with the specified name from the symbols font into the text. When the user would edit the text on the score, they would add those symbols using the special characters palette, just like they can do with other text objects in the score.

But I wonder one thing: when we make the texts on text lines editable in the score, do we also preserve the text field in the Properties panel? If we get rid of them, how will the user add text to a text line if there is no existing text yet?

And if we drop the idea of begin/continue/end text, but instead allow the user to customise the text for each segment individually, we need to be careful. One potential problem is that the system breaks may be different in the full score and in the part score, so accordingly, there might be three segments in the full score and only two in the part score. We would need to handle this sensibly. Also, we need to do something sensible when the layout of the score changes so that segments are created or deleted.

[Tantacrul]

@cbjeukendrup - FYI, this is definitely a lower priority than the Save to Cloud. So, if you need to choose, don't choose this!

[MarcSabatella]

This seems like an excellent candidate for a Community tag. Missing features relative to MU3 are a major pain point for a lot of users, and this is one that comes up quite often. I think a single control for the style of begin/continue/end will cover enough cases to be worthwhile for now.

Although, one thought - I'd have expected to see these text formatting controls on the Text tab instead of the Style tab. And with that in mind, it becomes a bit easier to see how to allow separate controls for "continue" text but perhaps hidden behind another button to be added later.

[bkunda]

Although, one thought - I'd have expected to see these text formatting controls on the Text tab instead of the Style tab

They actually sit beneath the respective text line options (for an example, see the way "tempo" text currently works). So they are not actually a part of the line options.

[bkunda]

But I wonder one thing: when we make the texts on text lines editable in the score, do we also preserve the text field in the Properties panel? If we get rid of them, how will the user add text to a text line if there is no existing text yet?

Just quickly on this: I don't think I ever suggested removing the text fields from properties. My suggestion was only to enable making the text element itself editable on double-click (and individual glyphs therein style-able). I don't see why this would preclude retaining the existing text input fields (they themselves wouldn't necessarily need to reflect the chosen styling, btw).

[rgreen5]

Will the text-formatting options include frame properties? If so, #16876 could be closed.

[bkunda]

With the benefit of time (this issue is now very old) – and since some objects now contain three tabs instead of two – I think it might actually make sense to add the style options to the "Text" tab (as @MarcSabatella suggested above).

I can just see it looking silly to have two separate "Text" headings for the same object in the same panel.

The actual text style header might then have to change, perhaps to "Formatting". Or maybe it doesn't even need a header – just a divider line?

@avvvvve this might just need a bit more design attention if you have the time.