Adding text to a hairpin - odd behaviour.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.4.1.9660, revision: 20414b2
I was trying to add square brackets as begin and end text to a hairpin to show that it is an editorial addition. I found some odd and slightly inconvenient behaviour.
If I enter a hairpin and leave it selected or select a hairpin by clicking on it, the properties of the hairpin are displayed in the inspector, all as expected. In the inspector if I open the text properties panel, and tick the Begin text box the expected boxes are shown to allow text entry and text properties adjustment, again as expected.
Now comes the odd behaviour. When I click within the box labelled "Text" to enter the left bracket, the text entry boxes immediately collapse and the Begin text box is unticked. If I tick the Begin text box again, the text entry boxes re-appear and this time, the text entry boxes do not collapse when I click to start entering text. The same thing happens with the continue and end text tick boxes.
If, starting from an unselected hairpin, I click on it to select it and then right click and select Edit element from the contextual menu, and then tick the Begin text box, this time I can enter text into the text entry box straight away.
It is not a big deal, I do what I want to do quite easily, but it just takes more clicks than I would expect and the behaviour seems odd and inconsistent.
Comments
Definitely feels like a bug, possibly connected to the new single-click behavior for lines. I recommend submitting to the issue tracker.
FWIW, there was talk recently of removing the text fields for hairpins entirely because normally they aren't relevant, thanks for providing a good use case where they are!
In reply to Definitely feels like a bug,… by Marc Sabatella
I don't consider brackets to be a valid use of hairpin text. Brackets are a reasonable request, but not via text because it will be difficult to get the right feel in terms of musical font vs text font, etc. I would prefer this to be done via a "has bracket" checkbox, or even better via some method of semantically saying "this hairpin is an editorial addition".
I can imagine all elements having a "source" property, and if the source is set to anything other than "original" then the element will be given a bracket (or displayed as a dotted line, etc.). The type of bracket (or spacing of the dots/dashes) could be used to distinguish between editorial elements that were added by the transcriber vs. ones that existed in the score they were transcribing.
In reply to I don't consider brackets to… by shoogle
I agree adding brackets as text to a hairpin is not ideal but one uses what works even if it is not designed for that purpose.
I have also attempted and so far failed to add brackets to a slurs and this prompted me to make the more general suggestion of facilitating the addition of brackets to all elements (or at least those that are sensible) to indicate editorial changes and additions. See #300462: Add square brackets to score elements to indicate editorial additions/changes.
I like your suggestion of how such a thing might be implemented in practice. Is this how it is done for accidentals? if so, the wider implementation may not be so far off.
In reply to Definitely feels like a bug,… by Marc Sabatella
Issue created #301138: Entering begin/continue/end text for a line only works on second attempt.