Textline properties: reintroduce missing text edit field

[bakajikara]

Resolves: #14928
Resolves: #16368

• I signed the CLA
• The title of the PR describes the problem it addresses
• Each commit's message describes its purpose and effects, and references the issue it resolves
• If changes are extensive, there is a sequence of easily reviewable commits
• The code in the PR follows the coding rules
• There are no unnecessary changes
• The code compiles and runs on my machine, preferably after each commit individually
• I created a unit test or vtest to verify the changes I made (if applicable)

I'm new to both the MuseScore code and QML, so please let me know if I'm doing something wrong!

[cbjeukendrup]

From a technical point of view this looks very good!

@bkunda @oktophonie Could you test this from a design perspective?

• It brings back the "end text" field for all types of text lines
• It brings back the "text" tab for pedal lines.

Personally I would be happy with this, since these options might be useful for some use cases, and there is no reason to hide them (except maybe simplification, but that doesn't seem necessary to me; I can't imagine that users get confused when they see an "end text" field in addition to a "beginning text" field).

[bkunda]

I've had a look at this, and the solutions do now make the text settings more consistent with other text line objects, so this gets a tick from me!

Only thing is that, instead of the reset button for 'Beginning text', 'Text when continuing to a new system', and 'End text', we usually adopt the "three dots" menu icon with these options:

I don't see any reason why this wouldn't also apply to pedal lines:

Other than that, I think this is a good fix. Thank you!

[bakajikara]

This is because there is no default setting for pedal line text style, which has not existed since before MuseScore 3.
This is probably intentional, since it is common to use pedal lines with different text in a single score.

[bkunda]

@bakajikara I've just made a quick video to demonstrate the problems I'm having with this reset button (one purely visual, the other functional):

Screen.Recording.2023-03-17.at.1.17.13.pm.mov

I should add that, if it's somehow not possible to save a default pedal style (I can't imagine why this wouldn't be possible, but that's what I gleaned from your message above), then we can just disable the context menu option "Save as default style for this score".

But ideally, the "reset" button for pedal marks should just return the syntax that triggers the correct symbol (in just the same way that resetting any other text object returns the default text).

Hope that makes sense!

[bakajikara]

In my last commit, I added a pedal text style. This solves the visual and functional problems described above.

However, there is a problem with this:
Previously, MuseScore had no style setting for pedal text, and the default value for pedal text was an empty string.
So when loading a previous score, the empty strings of the pedal lines are replaced by the default pedal symbol string of the current style.
I am working on solving this problem but do not know how to do it. Can someone please help me?

[cbjeukendrup]

@bakajikara I think there are two solutions:

1. (easy) Make the default value for the new style setting an empty string. Then we still provide the ability to change that default style as requested, but for the rest nothing changes.
2. (more complicated) Handle this while reading older files. This requires us to update the file format number (which we need to do anyway for 4.1), so that you can detect when a file is older than the new number, and when that is the case you set text to an empty string unless something else is explicitly specified. However, since this requires the file format to be updated, which we haven't done yet, this is maybe not directly actionable for you.

[bakajikara]

Thank you very much. I decided to use solution 1 for now. (But ideally I think we should use solution 2.)

@bkunda
I have solved the visual problem you mentioned. The functional problem will be solved by changing the default styles sometime before version 4.1 is released.

[bkunda]

Great, thank you @bakajikara – I'm happy with this solution for now.
@cbjeukendrup @RomanPudashkin this works as expected, so all good from my end. It's ready for a final code review and merging if you guys are happy too 🙂

[cbjeukendrup]

@bakajikara A rebase is needed.

[bakajikara]

@cbjeukendrup Done👍

[cbjeukendrup]

@RomanPudashkin Could you please review it?

[RomanPudashkin]

@bakajikara could you please rebase it again? I'll merge it after that. Thanks!

[RomanPudashkin]

@bakajikara could you please also open the same PR but for the 4.1.0 branch? Thanks!

[bakajikara]

@RomanPudashkin Done!

[RomanPudashkin]

@bakajikara please fix the failed unit test

[RomanPudashkin]

@bakajikara the build errors are fixed here:
#18409

[RomanPudashkin]

@bakajikara please rebase your PR (the CI checks will be fine after that). Thanks!