Line text will not recognize edits using <sym>

• Mar 14, 2016 - 19:34
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

Cannot enter symbols into custom line text, including modifying current symbols. The <> symbols wind up being input wrong.

To replicate:

1) Place a pedal line
2) Modify pedal line by, say, putting parenthesis around the pedal symbol

Expected: Pedal line appears properly with parenthesis on either side
Actual: "(keyboardPedalPed)" appears in place of the pedal symbol (parenthesis included).

Comments

• Mar 14, 2016 - 20:09

Confirmed. Worse that that - *any* edit to the line properties, including simply deleting it, hitting OK, then going back and restoring it to what it was before, will break the recognition of the symbol. I will look at this; I think this is crucial to fix for 2.0.3

Reply

• Mar 14, 2016 - 21:09

Cause is here:

https://github.com/musescore/MuseScore/commit/cdb2bb6b879139eb42ec3437f…

In an effort to protect the "&" (and presumably other characters that might cause errors in Xml), we lost the ability to process the <sym> declarations, because the angle brackets are being turned into escape sequences.

I'm not sure the best fix. We *do* need to escape &, <, and > symbols within the text, but *not* if they form part of a valid sym definition. We can't put off the escaping until we write the file, or unescaped &, <, and > characters won't appear in the score.

I have a solution in mind: when processing the dialog, we could replace all instances of <sym> or </sym> with some other placeholder text, then escape the remaining text, then replace back. I'll try this out and submit a PR if it seems viable.

It occurs to me we could also do something like this in the Staff Properties dialog, which would then allow <accidentalFlat> to be used in an instrument name. Currently there is no easy way I know to get a flat sign into the name if it isn't placed there automatically already. Or is there?

Reply

• Mar 14, 2016 - 21:50

FWIW, the approach I mentioned above does work, but in testing it I encountered another ill effect of the way we are using xmlString(). The following is reproducible in 2.0.3 and the master:

1) my first score
2) add a line
3) line properties
4) change text to 1 & 2
5) OK
6) line properties - notice the & is now escaped as &amp;
7) add a "." or make any other change

Result: text changes to "1 &amp; 2.". The & in the escape sequence is now being re-escaped, thus breaking the original escape sequence. We probably need to convert those escape sequences back to their original text when populating the dialog.

Chance are there is another way of dealing with all this. Historically we haven't done a great job of it, it seems to me.

Reply

• Mar 16, 2016 - 17:49

I need to look at this with a fresh mind but the only good way for me is to get ride of <sym> in the UI and have a generic way to enter symbols in UI elements. It will help here in lines, in instrument names, in the new score wizard if you want to name your score "Alla Breve C|", in the header/footer, even in the time signature properties to support notes in the denominator.

Somehow we already have the symbol palette (F2), we can add a QToolbutton to trigger it. The only unknown is how to handle multiple font in QLineEdit but in the worse case, we would use QTextEdit which support HTML/rich text and write an HTML <--> MuseScore crazy text format converter (or even subclass QLineEdit)

Reply

• Mar 16, 2016 - 18:43

Yes, that's the way to go long term for sure. Not sure we want to go to that much trouble for 2.0.3 though? I could imagine this requiring a version bump to do well, but maybe not.

Reply