Allow brackets to be invisible

[mike-spa]

Resolves: #15741
(partially)

I'm opening this PR mostly as a design question for @Tantacrul or @bkunda, whenever you have a spare minute to look into this. Currently, if you click on an bracket and toggle the "Visible" switch, nothing happens (see related issue). Clearly this is bad.

With this PR, if you toggle the "Visible" switch on a bracket, it will make all instances of that bracket in the score invisible (see for example here: brackets are now invisible also on the second page).

So, the first question is whether this is acceptable and/or sufficiently intuitive as it is. Surely it's better than a switch that doesn't do anything, and codewise it is quite trivial, so I'd be inclined to put this in.

The second question is that, in future, we want the ability to make a single instance of a bracket invisible, so at that point we'd have to decide whether the "Visible" toggle in the property panel refers to a single instance or to all of them, and how to communicate the difference. Again, what I'm doing here is quite trivial codewise so it won't interfere with the future, more complete solution. I just don't want to make shortsighted design choices.

Let me know what you think!

[bkunda]

Terrific that we're fixing this @mike-spa.

I think for now, there would be a practical advantage in conforming to the regular 'rule' about the Properties panel: i.e. the visibility toggle only affects the selected element (in this case, bracket).
This allows this function to be used in cases where the user may want to affect only a selected system, and not the whole score (I don't have a real-world example of this to draw on at the present minute, but my intuition tells me this might occasionally be needed).
Should the user want to effect this setting across the entire score, they have the Select > Similar, and Select > Similar on this stave options, which I think make more sense as a way of toggling visibility of multiple items.

Just as a side observation, the V keyboard shortcut doesn't seem to be effecting any change in this PR (at least on macOS).

[oktophonie]

The problem here is that there really is only one instance of the bracket in the score; its recurrences on each system are not explicit, discrete items, nor are they really attached to anything. These 'system header' items (brackets, clefs, key/time sigs, instrument labels) are set at the beginning of the score, and then are just automatically replicated on each system, though subject to certain rules (e.g. we can use short instrument labels after the first system, or hide brackets when they span only one stave, etc). Some of these things can change during the score (via a clef/key/time sig change, or an instrument change), but those changes are explicit at a certain point in the music and then are, again, automatically reflected when the next system(s) are laid out.

While it is highly desirable to be able to make these editable on a per-system basis, that requires first figuring out a way to define a particular instance of a bracket as being an explicit instance of itself (rather than automatic), and also considering what happens to any changes made to it if the layout of the score changes - by no means impossible, but rather beyond the ambition of this PR.

[bkunda]

ok this is very helpful additional information @oktophonie.

If it is, as you say, highly desirable to be able to make these editable on a per-system basis (I'm sure I agree with you here), then I think it would ultimately be worth figuring out a way to do it. The behaviour I specified in the comment above would probably be my preference from a UX POV, because it involves no additional UI components and, once learnt, "should" be straightforward to adopt.

As far as this PR is concerned though, it does solve the immediate problem of non-responsive functionality, which is good. If we merge it, we might just have to manage some questions about why the action affects the score globally (to which we can affirmatively respond that we are working on a solution).

[mike-spa]

@bkunda thanks for the help, now I know what kind of user interaction we want to be able to achieve eventually. As Simon pointed out, modifying the properties of a single instance of a bracket requires some very careful work under the hood, because it is part of the larger problem of being able to locally override global settings (something that Musescore simply can't do atm).
For now, allowing to toggle "Visible" globally for a bracket seems to a good intermediate compromise (certainly better than a non-responsive funcitonality). And now also the "V" shortcut should work.

[bkunda]

For now, allowing to toggle "Visible" globally for a bracket seems to a good intermediate compromise (certainly better than a non-responsive funcitonality). And now also the "V" shortcut should work.

Completely agree with this. Thanks @mike-spa!

[RomanPudashkin]

What will happen if the user opens their old score that does not have this tag for brackets?

[mike-spa]

I double checked to be sure. The "visible" property is read from here after the other properties. Old files don't have the "visible" tag so it will just default to 1 (i.e. visible, as expected).

[RomanPudashkin]

Ideally, you should add a unit test that verifies this. You can add it to your next PR

[jonarnoldmusic]

Forgive me if this is not the best place for this, but a real world example of why hiding individual brackets would be useful is the current solution for incipits. Currently, you have to use a horizontal spacer, which means the both areas around the spacer have brackets, but the first one should ideally not.