Do we need all of the on-off switches in properties panel?

Dear Doricorians,

Do we need all of the on-off switches in properties panel?
Some of them are necessary, but some of them seem to not be required.
For example, the on-off switch for the “Border” in the text properties is necessary:


As you see in the example above, there is no on-off switch for “Position”. However, there is an on-off switch for “Placement” in Dynamic properties. I think it can be removed.
Screen Shot 2020-02-11 at 8.53.29.png
I think the following on-off switches are also redundant. They can be got rid of:

  • Prefix
  • Suffix
  • Beat-relative position
  • Text alignment

We can reduce a step in the workflow if the on-off switches do not exist.

Dorico already does not have an on-off switch for the “Position” for “Text”.
To change the position of a text, we need just a click of the button “above” or “below”.
To change the placement of a dynamic, we need two clicks: firstly clicking the on-off switch, then clicking the button “above” or “below”.

What do you think about this?

You need the switches in order to know whether you’re overriding the global options or not. Let’s imagine for a second that you just have the options themselves in the properties panel, and generally they do what they want but sometimes you’ve overridden them. In your suggested scenario, if you then change the global options then you’d find that individual properties you’d specifically set would be undone.

There is no global option for whether text should be above or below - it’s always above by default (unless it’s non-vocal dynamics, in which case it’s always below by default) hence there’s no need for a toggle.

You might have a point with regard to the prefix and suffix toggles, but again, it’s consistent with the concept that whenever a global setting is being overridden there’s a toggle. Neither you nor I know what the coding consequences would be, either - this is about development priorities just as much as it’s about user experience.

This has been discussed ad nauseam. Please please search.

Our view on this, as I’ve said many, many times, is that having the toggle switches has both informational value (i.e. it allows you to see which properties are overridden) and functional value (i.e. it allows you to selectively clear any override). The reason that some properties do not have toggle switches is that those properties cannot be unset: they must always have a particular value.

I have also said many, many times that we are not going to change this. We believe that the above benefits – both informational and functional – outweigh the inconvenience of having to enable the property and then set its value.

We are of course always thinking about ways to improve the experience of working with the Properties panel, and we have a lot of ideas in that area, but whatever we end up doing, removing the toggle switches will not be part of those improvements.

That’s great! Would it be possible to not disable the UI elements for unchecked properties, and to automatically check properties for which you make settings? For example, the MacOS print window works this way. In this screenshot, the ‘from’ and ‘to’ fields are currently irrelevent because ‘all’ is selected. But you can still fill something out there, and if you do, the second radio button (from … to …) is automatically selected (on the blur event of the text field). Then there are not 2 actions needed to set a property, but only one.


Screenshot 2020-02-11 at 13.07.04.png

2 Likes

That’s doable in principle for some kinds of controls, but not for all of them, e.g. a checkbox cannot both show that it is unset and enabled, since that is the same as it being switched off, and there is a semantic difference between a property being set and switched off and a property not being set, which is why we disable all of the dependent controls. As a result, it makes it difficult in full generality to allow the controls themselves to be the means of enabling the toggle switches, even if we wanted to (and I’m not at all convinced that we do want to).

I am very sorry that I did not intensively search the topic related to my question.

I now understand that the toggle switch has informational and functional benefit, but I think this can be achieved with other algorithms.

Please look at the following example which has three text buttons. Please take your attention that the leftmost button does not accept mouse click, and it just changes the text according to its status. Thus, we need only one click to override the general preference, and the informational part is automatically executed. This could be also related to what [bold]mth[/bold] wrote, I think.

I am very sorry that I do not know how to program such an algorithm in Qt. I wrote the algorithm using MAX by ‘cycling 74’.

1 Like

I keep wondering what part of “we are not going to change this” people do not understand. :unamused:

Given that one of the most fundamental lessons in life is that change is inevitable, it’s a very brave man who insists otherwise. :wink:

I think the on-off switches work well just as they are. Additionally, they’re as informative as they are functional -I keep seeing a whole bunch of stuff in the bottom panel I never knew I could do. Maybe in time the script function could be developed to enable users to hotkey things they change all the time.

The switches could be a tad bigger - but that’s already come up in another thread.

one more example for automatic detection:
by counting the length of typed strings, the toggle button can be automatically switched on or off.

1 Like