Changes made in Text Properties do not affect all selected elements

• Jan 26, 2014 - 04:55
Reported version
2.1
Type
Functional
Severity
S4 - Minor
Status
active
Project

When multiple elements are selected in a score, and text properties are used to change them, only the first item that was selected is effected by the change. All other elements remain unchanged.

I have attached a score that can be used to show the problem.

1) Open the attached score
2) Right-click the first dynamic marking on the soprano line
3) Go to 'Select' and either choose 'All Similar Elements', or 'All Similar Elements In Same Staff'. You will see that now all of the dynamics are selected
4) Right-click the first dynamic marking and choose 'Text Properties' - note that all dynamics remain selected.
5) Change the property from 'Dynamics' to 'Dynamics vocal'
6) Click 'OK' to close the 'Text Properties' dialogue.

The result is that only the first dynamic that was selected has taken the new style, but all of the rest remain unchanged. The expected behavior is that all of the elements that were selected should take the new style.

Attachment Size
test.mscz 2.11 KB

Comments

On a hunch, I looked at this and see that the issue only seems to affect dynamics. That is, if you right click a different type of text - say, a staff text - then do select all similar, then right click one again, text properties, and change style, the change *does* affect all selected items. Dynamics apparently are handled differently.

I suspect this is related to http://musescore.org/en/node/24311#comment-94016. I thought an issue had been submitted on this, but I can't find it. So I'm submitting that separately.

EDIT: #24508: Change to text style for dynamics not preserved across save/load

Title Text style change via Text Properties does not affect all selected dynamics Changes made in Text Properties do not affect all selected elements

Either I was dreaming, or the behavior has changed - changes made in Text Properties only affects the "current" text element regardless of how many are selected. This applies to any changes - selecting a different style, changing size, etc.

1) create score
2) add two staff text elements
3) select both
4) right click one
5) text properties
6) change size
7) OK

Result: only the element you right clicked is affected

This is especially problematic right now as there are no more text properties in the Inspector, which would otherwise be another way to affect text properties for a selected group of elements. Of course text style is still the way to go if you want to affect everything at once, but one thing I would want to use Text Properties for is to apply "Reset to style" globally after importing a score.

As far as I can tell, no contextual menu action is applied to all the selected elements: they all affect the right-clicked element only.

It is true that rather few contextual menu actions remain which affect individual element properties, but text properties are an important exception.

Also: an element does not need to be selected to bring the contextual menu up; you may have a number of texts selected, right-click an unselected one and the contextual menu would pop up on this one, independently from any selection. Which would be the expected behaviour in this case?

A) Apply the change to the clicked element only
OR
B) Apply the change to the clicked element AND to all the selected text elements?

It would be rather easy to add a loop on each selected text applying the changes to all of them. But is this what would be expected on the majority of cases?

My personal answer is:

1) If the right-clicked element is selected, apply the change to all other selected texts
2) If the text is not selected, apply the change to it only.

More opinions are welcome.

M.

P.S.: It should be noted that, given the current structure of ScoreView::elementPropertyAction(), if more actions would be required to act on all selected elements, the loop described above would have to be repeated for each of those actions.

The 1.3 behavior works for me. From memory, all items do apply to all selected elements assuming you right clicked one of the selected elements. If you right click an unselected element, the act of right clicking clears the selection. Whether that's how it works in 1.3 or not, I think that's what I'd expect.

More thoughts...

1) Reset to style
Regarding the specific use case quoted by Marc -- resetting to style a number of textual elements --, going through the props dlg box is not going to work. Let's assume the dlg code had been modified to work on all selected elements:

  • select a number of textual elements, maybe all of them
  • right-click on one of them and choose "Text Properties"
  • press [Reset to style] button => dlg settings change to the default settings of the style of the clicked element
  • press [OK] button => all the selected elements would change to the style and the settings of the clicked element.

which is not one would normally expect, I believe.

The "Reset to style" operation is somewhat special and the only reasonable way to achieve the intended result (reset all selected elements each to its own style defaults) is to add the operation as an independent contextual menu item.

I know this goes against the trend of removing items from the right-click menus, but I think this specific case could qualify as an exception.

I agree with Marc that resetting textual elements to style defaults is a rather important operation for 'cleaning up' 1.x scores read into 2.0 (and perhaps also for scores imported from other formats); so, it may make sense to provide a specific and simple way to do it.
_________________________

2) Selecting
if I am not mistaken, the 1.x working of selection was, something like this:

  • with right-click on an unselected elements, any selection was cleared, the clicked element was selected and the menu command operated on this element only
  • if the element was selected (maybe as part of a larger selection), any existing selection remained and the menu commands operated on all selected elements or on the clicked one only according [Ctrl] was pressed or not (I never clearly understood when [Ctrl] was supposed to be pressed, so I kept [Ctrl] pressed for the whole process!).

In 2.0 this has changed: right-clicking an elements does not change any existing selection. I assume there were reasons for that. So, I would not change this behaviour without an explicit statement about the rationale of this change from the core developers.

Thanks,

M.

Regarding 2, I guess I don't care. If right click doesn't clear selection, then text properties after right clicking an unselected item can do anything it wants - apply to just the right clicked item, apply to the selected items, apply to selected and right clicked item.

Regarding 1, my normal use case wouldn't have mixed selections. I'd right click one rehearsal mark, select all similar, text properties, reset to style. So it wouldn't matter that it wasn't actually setting each to its own style. But I would also say I'd really prefer to do this and other operation from the Inspector. A number of useful text properties were present in the Inspector up until the text changes back in January but are gone now.

Currently the inspector has no internal method of performing a callback (as "reset to style") would require) on items. Some refactoring would be required to add this. This may be useful elsewhere too, but if this is an isolated need, a new context menu item for Reset to Style in this specific case would not be horrible (especially if we are looking to remove the Text Properties item and have everything in there in the Inspector instead).

Came again: on the French forum: https://musescore.org/fr/node/104486
A user wants to distinguish chorus lyrics vs. verse lyrics in bold character.

He notice and regret to not benefit the same behavior of the 1.3 via the Text Properties.

You may of course create a text style ( but a rather complex procedure for some users: you have to create this new style, then Save it, and finally Load it at each new score)

Despite these proposals, the user prefers 1.3 to create scores ( type of choir scores) with version 1.3, with bold chorus via "text properties", and then open these scores using the 2.0.2 and then save.
A pity, right? :(

Rather than load the text style for each score, simply save it as a template. Then all scores you create from that template will have that bold type available. And in 1.3, how does the user select the lyrics to be made bold? I can't remember if it has the Select / More / Same verse option. But in any case, it's literally only three extra clicks to create a new text style compared to using Text Properties. Perhaps you could help explain the procudre to him?

1) right click a lyric
2) Text Style
3) New
4) type a name
5) OK
6) press Bold button
7) OK

The only additional steps compared to using Text Properties. But the advantages are many.

Rather than load the text style for each score, simply save it as a template. Then all scores you create from that template will have that bold type available. And in 1.3, how does the user select the lyrics to be made bold? I can't remember if it has the Select / More / Same verse option. But in any case, it's literally only three extra clicks to create a new text style compared to using Text Properties. Perhaps you could help explain the procudre to him?

1) right click a lyric
2) Text Style
3) New
4) type a name
5) OK
6) press Bold button
7) OK

The only additional steps compared to using Text Properties. But the advantages are many.

"And in 1.3, how does the user select the lyrics to be made bold?"
I suppose like this, with Shift and drag:
verse.jpg
"Rather than load the text style for each score, simply save it as a template."

Yes, better, time saver, thanks (don't know why I have not thought about it, I produced several templates yet! Probably because it is "only" for a text style?)

"Perhaps you could help explain the procedure to him?"
Of course, I will do it.