Text line style #30151

miiizen · 2025-09-26T14:41:06Z

Resolves: #14238 (almost entirely)

This PR enables styling of text line's text via the properties panel. Currently, beginning, continuing and end text are all controlled by the same text panel and therefore must have the same style. However, MuseScore 3 scores with different styles for beginning, continuing and end text will still preserve these differences.

Screen.Recording.2025-09-29.at.14.22.14.mov

The PR also fixes a bug involved in applying text line text styles (eg. Volta) to regular text (eg. Staff Text) and vice versa.

avvvvve · 2025-09-29T17:25:26Z

Looks great! From a quick scan, the bits of the original task yet to be resolved are:

Independent text styling for beginning/continuing onto new system/end text of the same element
- Needs some design and likely isn't so high priority
Double-clicking the text in the score to edit it
- We know this is possible because of repeat play count text, but that involved a lot of testing time

We could create follow-up issues for both. Was there anything else?

miiizen · 2025-09-30T09:50:44Z

@avvvvve I believe that's it. I would recommend double click to edit to be implemented at the same time or after independent styles for beginning/middle/end text.

mike-spa

Very few comments, mostly just questions. Great work!

mike-spa · 2025-10-01T07:59:59Z

src/engraving/dom/engravingobject.h

    bool onSameScore(const EngravingObject* other) const;
    const MStyle& style() const;

+    virtual EngravingObject* propertyDelegate(Pid) const { return nullptr; }


Could you explain why this change was necessary? I'm not sure I get it from just looking at the code

This one wasn't 100% necessary - I wanted to add a property delegate call to propertyFlags and casting to EngravingItem immediately for such a basic operation felt wrong. It's also the only property related function which isn't in EngravingObject.

mike-spa · 2025-10-01T08:02:54Z

src/engraving/dom/hairpin.cpp

    : TextLineBaseSegment(ElementType::HAIRPIN_SEGMENT, sp, parent, ElementFlag::MOVABLE | ElementFlag::ON_STAFF)
 {
+    m_text->setTextStyleType(propertyDefault(Pid::TEXT_STYLE).value<TextStyleType>());
+    m_endText->setTextStyleType(propertyDefault(Pid::TEXT_STYLE).value<TextStyleType>());


Perhaps can be rewritten more concisely as m_text->resetProperty(Pid::TEXT_STYLE)?

Using resetProperty calls initTextStyleType which resets all text style properties. For text lines, these are stored in TextLineBase. Because this is being called in the segment constructor, this happens at layout. This caused issues with opening files, as it would wipe any custom formatting the user had saved on first layout of the score.

mike-spa · 2025-10-01T08:08:52Z

src/engraving/dom/text.cpp

+        return parent();
+    default:
+        return nullptr;
+    }


This function reads a bit clunky. For a function this simple I'd perhaps put the positive case first so it's easier to read, e.g.

if (id == Pid::TEXT_STYLE && parent()->isTextLineBaseSegment()) { return parent(); } return nullptr;

Also, I think parent() may be null in some cases so perhaps nullchecking it before using it is worth it just to be safe

mike-spa · 2025-10-01T08:13:58Z

src/engraving/dom/textbase.cpp

    const TextFragment* tf = ldata->textBlock(static_cast<int>(startRow)).fragment(static_cast<int>(selectionStartCol));
    CharFormat resultFormat = tf ? tf->format : CharFormat();

+    bool allBlocksEmpty = true;


Could you explain what problem this is solving and why normal text (i.e. text that doesn't belong to a TextLineBase) didn't need this?

The issue here was that getting font face/size/style from empty text with no fragments returned "" for font face, 12 for size and FontStyle::Normal for style no matter the value for these properties in the text style. This wasn't visible before because selecting an empty text item isn't possible and editing text to be empty doesn't remove the last fragment.

It is now visible because we are using the properties panel to edit the properties of at least 2 text items at once. For example, a volta has beginning text of "1." and end text of "". Without these changes, "1." has a font face of "Edwin" while the end text has a font face of "". This puts the properties panel in an indeterminate state:

mike-spa · 2025-10-01T08:19:06Z

src/inspector/models/text/textsettingsmodel.cpp

+    switch (propertyId) {
+    case Pid::BEGIN_FONT_FACE:
+        setPropertyValue(m_elementList, Pid::CONTINUE_FONT_FACE, newValue);
+        setPropertyValue(m_elementList, Pid::END_FONT_FACE, newValue);


I wonder if it would be more solid to handle this in the setProperty method. That would guarantee that any time anybody sets Pid::BEGING_FONT_... you also set CONTINUE_FONT_... and END_FONT_....

Ah, maybe that's not possible because of back compatibility when reading older files.

Yes, we need to use the settings to enforce this for compatibility

cbjeukendrup

Couple of comments. I haven't completely finished reviewing yet, so some more might follow later.

src/engraving/dom/engravingobject.cpp

src/engraving/dom/spanner.cpp

cbjeukendrup · 2025-10-02T01:46:28Z

src/engraving/rw/read410/tread.cpp

 {
    if (tag == propertyName(pid)) {
+        if (pid == Pid::BEGIN_TEXT_OFFSET) {
+            LOGI() << "ofs";


Left-over log

cbjeukendrup · 2025-10-02T01:49:05Z

src/engraving/dom/whammybar.cpp

+#include "dom/text.h"
 #include "score.h"
 #include "system.h"


Nitpick:

Suggested change

#include "dom/text.h"

#include "score.h"

#include "system.h"

#include "score.h"

#include "system.h"

#include "text.h"

same in other files. But I can also clean this up myself, I'll be doing an includes cleanup PR anyway.

cbjeukendrup · 2025-10-02T01:52:37Z

src/engraving/dom/textlinebase.cpp

+    case Pid::BEGIN_FONT_FACE:
+    case Pid::BEGIN_FONT_SIZE:
+    case Pid::BEGIN_FONT_STYLE:
+        return style().styleV(getPropertyStyle(propertyId));


Why do specifically the begin properties have this, and why can't it go via SLine/EngravingObject::propertyDefault?

cbjeukendrup · 2025-10-02T01:55:00Z

src/engraving/dom/textlinebase.cpp

 bool TextLineBase::setProperty(Pid id, const PropertyValue& v)
 {
    switch (id) {
+    /// In >=4.6 text line begin, continue, and end text should all have the same style


The comment doesn't seem to match the method; perhaps the comment should rather be in the inspector code? The fact that they all have to be the same is (and should be) only a temporary UI limitation, but in the engraving code nothing essential is changed, is it?

src/engraving/dom/textbase.cpp

Return defaults

Text line styles use different Pids. Ensure the correct Pid is used.

Also tidy the files a bit

miiizen marked this pull request as ready for review September 29, 2025 13:23

miiizen force-pushed the textLineStyle branch 2 times, most recently from afc3245 to 263300f Compare September 29, 2025 13:40

its-not-nice requested a review from mike-spa September 29, 2025 14:17

miiizen force-pushed the textLineStyle branch from 263300f to ae4599d Compare September 30, 2025 09:31

miiizen force-pushed the textLineStyle branch from ae4599d to c970497 Compare September 30, 2025 15:58

avvvvve mentioned this pull request Sep 30, 2025

Allow separate styling for different parts of text lines #30191

Open

its-not-nice approved these changes Oct 1, 2025

View reviewed changes

mike-spa reviewed Oct 1, 2025

View reviewed changes

mike-spa approved these changes Oct 1, 2025

View reviewed changes

mike-spa requested a review from cbjeukendrup October 1, 2025 09:37

cbjeukendrup reviewed Oct 1, 2025

View reviewed changes

src/engraving/dom/engravingobject.cpp Outdated Show resolved Hide resolved

src/engraving/dom/spanner.cpp Outdated Show resolved Hide resolved

miiizen force-pushed the textLineStyle branch from 17f168d to a4a7e99 Compare October 1, 2025 13:03

cbjeukendrup reviewed Oct 2, 2025

View reviewed changes

miiizen force-pushed the textLineStyle branch from a4a7e99 to e7c5113 Compare October 2, 2025 08:43

cbjeukendrup approved these changes Oct 2, 2025

View reviewed changes

cbjeukendrup mentioned this pull request Oct 4, 2025

Fix #24922, 26612, 29611: Refactor key signatures #29610

Open

8 tasks

miiizen added 11 commits October 13, 2025 09:28

Move property delegate to EngravingObject

3fab0e4

Check delegates when assigning property flags

3a3df1a

Assign text line text it's style when created

6028673

Fix getting text style properties from empty text

c403972

Return defaults

Add text settings to all text lines

f48a57e

Fix applying text styles

b4d6061

Text line styles use different Pids. Ensure the correct Pid is used.

Fix mu3 compatibility

ce206c0

Change text line properties from settings model, not DOM

0806ae2

Don't show position for text lines

c196316

Set default textline styles

39ab5bf

Also tidy the files a bit

Review fixes

0fc3f35

More review fixes

7ab75ea

miiizen force-pushed the textLineStyle branch from e7c5113 to 7ab75ea Compare October 13, 2025 08:35

its-not-nice merged commit 369220e into musescore:master Oct 13, 2025
12 checks passed

Text line style #30151

Text line style #30151

Uh oh!

Conversation

miiizen commented Sep 26, 2025 • edited by its-not-nice Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

avvvvve commented Sep 29, 2025

Uh oh!

miiizen commented Sep 30, 2025

Uh oh!

mike-spa left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cbjeukendrup left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

miiizen commented Sep 26, 2025 •

edited by its-not-nice

Loading