Minimum distance property for all kinds of fermata is not saved

• Oct 2, 2019 - 09:45
Reported version
3.2
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

1) Add a fermata to a score.
2) Change its "min. distance" property.
3) Save/reload file.

Result: minimum distance for fermata has its default value rather than that assigned before saving.

Possibly some other element types are also affected, I didn't check them yet.

The issue exists both in 3.1 (where that property got introduced) and 3.3 Beta2 versions.


Comments

Confirmed, all fermatas (fermata, short fermata, long fermata...) affected but not other articulations (tried a handful).

Title Minimum distance property for all kinds of is not saved Minimum distance property for all kinds of fermata is not saved

Sorry.

There might indeed be some other elements affected, but I know it does work for most. Most of my testing wasn't based on changing min distance directly, but rather moving elements into the skyline, which automatically updates min distance as necessary. This did cause me to miss one case, with lines, where min distance only got written if the offset had been changed due to how the line properties were handled. But I just fixed that (see #294728: Lines: Minimum distance is not saved with score unless it is part of the style).

BTW, that bug I fixed with lines is exactly why you don't want to move your write of min distance underneath the "if (!isStyled(Pid::OFFSET))". The reason it failed is we were only writing min distance if offset was changed also, because there was no separate checked for min distance. It might be uncommon to change min distance without also changing offset, but not unheard of. And that's what the isStyled() is checking - whether the property has in fact been changed from the default.

We'll see, once 3.3.0 final got branched off of master (or whether the 3.3RC branch gets used to branch of 3.3.0 final and some commits from master get cherry-picked)

Being able to edit comments (in forum or on musescore.com groups) any time is a bug, at least after replies edditing should be prevented. In forums on musescore.org, there is a time limit, in the issue tracker (where no replies really exist) there is no limit at all, but deleting is not possible on .org, just 'emptying' (it possible is on .com)

In reply to by Jojo-Schmitz

Well, to be frank, musescore.org is the first website I've every seen of having a time limit of editing and restriction of deleting. GitHub, Atlassian, and many more, they don't have that. I can see troubles arousing from no limits or restriction, such as overall replacing the topic, making all comments below invalid, or other tricks. But what if the user really wants to delete something? Do that by telling the maintainers?

Fix version
3.3.0