Text properties applied to elements not preserved on copy/paste, palette add
- create a custom pallet from advanced
- enable editing on fingerings
- use fingering string number 1 to a note to score
- change 1 to 2 and ctrl+shift+click copy the new fingering to the pallet
- use this new fingering to a note to score (works perfect)
but
- use fingering string number 1 to a note to score
- change circle to box and ctrl+shift+click copy the new fingering to the pallet
- use this new fingering to a note to score the fingering is shown with circle and not with box (wrong behaviour)
Comments
I believe this is because items added from the palette get added with style defaults, not any custom formatting. See also #34871: Custom styles in palettes, which deals with custom text styles as oppose to custom properties. I can see why custom text styles would not be good to support - the palette would then be rendered ineffective on scores that lacked the style - but text properties could be. I thought there was an open issue for this specifically, but I don't see one, so I guess this is it now :-)
It's actually kind of more of a feature request than a bug, but either way, would be nice to have this at some point.
the problem occurs also when you copy-paste a fingering with a box on the score from one note to another one.
True. Custom text properties are not preserved on copy and paste either, for fingering or any other elements. If this were changed, I suspect the palette would start working as well.
I wonder if there is a downside to this, though? Cases where we *wouldn't* want custom formatting copied?
i believe when you copy something that you should get excactly what you see.
For the record, copy & paste currently does preserve text properties when copying a range (eg, a measure that contains text). It's also preserved when using the "list" copy method for the elements that support this (eg, multi-select several lyric syllables, copy, click a note, paste). It's only direct copy of a single text element - which is indeed implemented as a "drop" operation - that fails to preserve text properties.
The trick, I guess, will be to get text added from palettes to still use the native style for the score if the palette item had *not* been customzied. That is, adding a fingering element from the palette should *normally* use the corresponding text style defined for the score. Only fingering elements in the palette that had specifically been modified before being added to the palette should be added "as is". And I'm not sure how available this information will turn out to be. I have a hunch that the best we will be able to do is tell if the element is different from the *current* text style, but that would also be true if the text style was modified, and we definitely need to be able to honor that.
Which is to say, this could be why things are as they are, and if so, they may have to remain that way unless we feel like making deeper changes. But maybe I'm wrong and it will turn out to be easy to tell. Still investigating.
If I create a new style with box frame and put it to pallet will it work?
No, see #34871: Custom styles in palettes. As I said, that's unlikely to ever work, since text styles are unique to each score, and a palette has to work on all scores. So text properties would have to be the way to do this. I actually just now got this working, I think. Still testing to do, but hopefully I'll be able to make this change soon.
https://github.com/musescore/MuseScore/pull/1605
Everything works fine for me, I could just use a check that my method for differentiating palette items from copy & paste is OK and won't cause problems.
Did you make the change?
Where can i test this?
Is it to the nightly build?
it hasn't been merged yet -> not yet in a nightly build
i exported a score with a fingering as musicXML file and when i open the exported file again it says it is not a valid file. Also if I had changed a circle to a box then at reload it makes the box as a circle.
Also if you have three fingerings, it allows you to select all of them by ctrl and click to each of them but then any action(copy-paste, text style, text properties) refers only to the last one clicked
@iglezos: these all seem to be separate and unrelated issues and should get reported as such.
And with sample score and precise steps to reproduce, please.
The fact that you can't copy and paste list selections (selections made by ctrl+clicking multiple items) is not a bug; it's just a feature not implemented except for a very few element types (lyrics, chord symbols, figured bass. The fact that text properties does not work for multiple selections is already reported as #24436: Changes made in Text Properties do not affect all selected elements.
Fixed in 4f7c1f33ae
Automatically closed -- issue fixed for 2 weeks with no activity.