Hi Daniel & team,
I have two very small requests for the properties panel:
Small things, as you can see, but would be nice to have! 
π
No, we’re not going to do that. You have to activate the property before you can set a value, as the buttons are disabled for a reason. We cannot show a state for a property that is not set.
Some of the properties that show checkboxes could live without them, but in the case where you have an engraving option to do something by default, you need the checkbox in order to make sure that you can set the value that is the opposite of the default specified in engraving options.
To 1.: Daniel, I feel like you’re missing the point here. I do clearly understand why the buttons dont show any state while the property itself is in “auto” mode. But that does not necessarily mean that it has to keep me from klicking on one of the button if I want the property to be overruled by this specific option. I think the Slurs buttons in the image are a perfect example: Whatever their state is now, when I klick the “bending upwards” button, I want the slur to be bent upwords, overruling the current “auto” mode at the same time.
I can see no good reason why Dorico would need to force me to 2 clicks for this. (Especially when I can see the option I want.)
As far as I have understood (please correct, if I am wrong) there are two “layers” of interaction.
The first one is ruled by the design of the application and its default set values.
The second one is the layer, where the user comes into play. Here you have to first show, that you want to overrule the defaults and then secondly show, what you want. This must be two steps obviously.
To #1
Yes I see your point Daniel, but Estigy captured the idea—one click instead of two. To me, the ideal would be for a click on one of the four “design” buttons to 1) activate that property (toggle switch on the left side) and at the same time, 2) enable the “design” button which was clicked (right side).
In other words, it’s just a programming change, not a software design change… the current behavior makes sense!
Or, even better: have a keyboard shortcut that activates the “slur design” property and toggles between the four designs… (I personally dislike having to move my hand away from the keyboard to grab the mouse! I know, 
— but when I’m fighting a strict deadline every second counts, and I’m flying through the music as I copy it from manuscript, no joke!)
To #2
I get it, you’re changing the checkbox state through the default setting in the engraving options. Makes sense! Perhaps we can implement e.g. “(mp)” in the popover to automatically add the parentheses? And implement “>n” to automatically enable the niente option on the dynamic being created?
Again, icing on the cake I suppose…
Thanks Daniel, Estigy, and K_B for your insights!
–π
For #1 there is a fundamental issue that the controls are disabled so you can’t click on them to activate them, and they are disabled because the switch enabling the override is turned off. This behaviour is a core tenet of UI design. If you had disabled controls that actually did respond to clicks then this would be violation of conventional UI behaviour, and we want to stick to established UI conventions wherever possible.
This is unfortunate, as I also was wondering when the „fix” for this will come up. If clicking the disabled button to enable the override is out of the question - maybe switching the override could automatically change the state of the button then?
Nikola
What would it change the state of the button to though? How does it know what value you want to set?
If I click on one of the images for slurs In the properties panel it is clear what I want to set, isn’t it?
The problem is that you can’t click on a control that is disabled - that is the same in every application. The UI framework won’t let you do it.
Paul, just thinking outside the box here… is it possible to start from an enabled state with the same default setting the software would choose upon creation with the setting disabled?
Then, we could simply click to override the design «or» switch it off ourselves if it’s creating issues.
People who are asking this question do not understand the construction of the software. If everything started as enabled, then Dorico could not apply its AI to anything.
There is too much worry here about saving one click. People do not understand (nor would I expect most people to understand) what they are sacrificing for that request to be fulfilled.
Derrek is on the right track here. There is a huge amount of complexity to the automatic values that Dorico has chosen under various circumstances, and it would be a massive undertaking to be able to automatically forward that internal value to where it is shown in the UI. Furthermore, even if we could do that, I think that would be of limited usefulness because if it automatically defaults to same state that has been determined internally then you will still need a second click to change it to something else because the reason for editing it is that you aren’t happy with the default. So you’ve still got two clicks.
I expect that in the fullness of time, the default settings for many items will improve so that (a) they either do the ‘right’ thing more often and require less manual tweaking, or (b) defaults for more of the properties will be set in the notation/engraving options so that your default score options will reflect your own preferences, and (c) these properties will be scriptable so that you’ll be able to make batch changes more easiliy.
Great explanation Paul, and if I had know that the above is a “massive undertaking” I would never have brought it up in the first place… 
Thank you for your insights! –π
I just answered your question about how Dorico could know what to set.
I know that it is not possible because of this limitation. But it could have been so and I personally would have liked that.
And Derrek this is nothing that I don’t understand but something I think is not necessary at least for me. I know what I want to change when I click.
As Paul has written later here I still hope that some day this behavior will get “worked around” with other possible features in Dorico.
I’m sorry, but your are wrong. I’m a programmer myself, I actually do that for a living, and I’ve come across this very same problem. We had an application where users had to click a checkbox to activate manual override, and in a second step had to choose or enter their own value. They didn’t like it from the very beginning and we had to change it.
It could be as simple as 3-state-elements (checked / not checked / “not set”) that you see in every application installer.
All I’m saying is: There are ways, if you really want the user experience to be more fluent in this area.
Yeah, the properties panel and the workflow…
Daniel wrote about a solution with kind of a popover for the PP, where you can reach single switches with a shortcut. Probably I am a bit late with my idea, and I assume it would not work on Mac, yet I still write it down here:
When you choose the PP with Crtl+8, you perhaps could set it automatically to active and the normal/standard function of the Alt-Key simultaneously is switched to inactive. So you can reach the single switches like submenus in menus when you hit the Alt-key: an underlined letter as an indicator. Then you can use the arrow-keys to move the switch and the space key to tick a box. After changing the chosen values and confirming with either enter or escape (if necessary), the PP becomes inactive (closes) automatically, and when you want to change a property again, you have to open it with ctrl+8 again…
Just thinking.
I have to admit that I also would like to have bigger and brighter letters in the PP 
, even if the design looks really cool like it is now.
Well, I’m not a software programmer myself and actually I don’t need to understand the construction of the software, as I don’t need to understand the Computer itself. But still this simple question isn’t really answered: is it for the programming cracks of you possible to enable the direction switch by just clicking on the slurs up field or is it not? In my point of view as a “dummy” user the handling right now isn’t really perfect and slows me down.
So Derrek says ‘yes’ and Paul says ‘no’, but his argument is some sort of “convention”. And here’s that “dummy” user again asking, why a convention should slow down his work …
But now let’s go to the party and all the fine dishes. Happy New Year everybody and keep on with your excellent work
I also don’t see why it couldn’t be one set of buttons that selects auto// etc., rather than the auto on/off button being separate. I think this was an early development decision so is probably not up for review, but it smacks of being one step too close to the programming flow-chart.
I think the explanation previously given, Steve, is that you still need to know whether a property has been overridden or not, which a sole dropdown can’t easily do.