An example: the default setting of a specific Fingering mark is Above the staff. I wish to flip it below.
To do this, I have to check the box for “Staff-relative position”. Once I do this, the “Above” setting is highlighted, and I must then click on Below.
Would it be fair to say that when I check the box, most of the time, I want to change the current setting, rather than ‘force-maintain’ it? So, it would save a click if Dorico automatically flipped such settings as soon as I check the box.
Options with more than two settings are perhaps more tricky, though there’s a certain logic to be applied there, too. Accidentals can Show, Hide or have Parentheses. Again, if I check on the box for an accidental that is currently hidden, I’m going to want to Show it. (And then possibly parenthesise it.)
In short: when I check the box to alter a setting, the current setting is almost always going to be the one I don’t want. Isn’t it?
I can see where you are coming from here, but suppose you changed the “default” for the option, in the engraving rules. Would you then want the dialog to do something different from what it was doing before you just changed the engraving rule?
Yes! If the default is “Above”, then turning on the switch (not a box) should automatically set it to “Below”.
If the default is “Below”, then when I turn the switch on, it should automatically go to “Above”.
Because by flipping the switch on, I want something other than the default.
(Obviously, if I’ve already set a property manually, I don’t want it altered when I change the global Engraving settings.)
Dear Benwiggy,
That is exactly something I asked for, quite a long time ago. That the software knows what the property is, so if I decide to tweak in the properties panel, that the choice that is NOT what is displayed on the score would be the one chosen in the properties panel by default. Of course this does work only on the 2-choices categories, but it would be some time and energy earned !
I’ve also asked for UI improvements like this. First of all, I find it annoying that I have to click the tiny switches and can’t click the labels, too (as label elements in HTML forms allow to do) in order to switch something on or off. And secondly I find it strange that you have to activate a setting in order to deactivate something. That’s a redundant interaction that should be avoided. But I seem to remember Daniel saying that this is supposedly not easy to change.
From what I recall regarting this topic, Daniel said that the underlying UI library doesn’t have this feature: Clicking on disabled fields simply doesn’t emit a click event in the first place that the application could then listen for (in order to activate the input field and set it selected, for example).
So what would need to be done is this: Create a third state (enabled, disabled, “enabled that looks like disabled”) for all types of input fields in order to have an input that looks disabled but (from a technical point of view) is not, so clicking it will in fact register a click event. Though it might sound easy, when dealing with a third party component this can be quite tricky. And it undermines the beauty of using a third party component in the first place.
As much as I would love (!) to see this UI change, I do believe that this will not happen anywhere in the next 2 or more years…
If clicking directly on the property can’t activate the switch, then having the switch auto change the setting is the next best thing.
Presumably, the code has to check the current value anyway.
Conversely, Dorico doesn’t show the current value in some places. When I manually change a frame’s padding, it changes to 1pt when I flick the switch, even when the existing value was 25pt or something else.
It goes without saying that these are footling details and, given the choice, I’d rather that the team spent time on new features!
We agree that it would be useful if properties could set themselves to the current value rather than just a fixed default value when you enable them. It’s difficult because each property potentially needs a different mechanism to determine that answer: some need to look at options in e.g. Notation Options or Engraving Options, others need to look at the actual music to figure out what the current value is. This is definitely something we would like to do but it’s decidedly non-trivial and even once the mechanisms exist to allow the determination of this data, it will have to be retrofitted to every property, which will take week or possibly months of work. That’s not to say we won’t do it, but it’s not a small job, and we have a lot of other stuff to do.
The more general complaints about having to enable and disable the switch or to have to enable the switch in order to turn something off – sorry, but that’s just how it’s going to be. This is not designed to be an encumbrance but rather to provide you with more information about what’s actually going on. You can tell at a glance whether something is overridden by a property, and you can efficiently selectively reset individual property values. You also need to have both the switch and the checkbox for some properties because something can legitimately be overridden either to be switched on or switched off: if one of these states was missing you would get unexpected changes when e.g. flipping the state of the Engraving Option that corresponds to that property.
Daniel, as much as I like the visual representation of what is “going on”, the fact that we have to click to enable an override bevor actually chosing the override value is an “encumbrance” to many of us. Of course it was not "designed to be an encumbrance, I would never assume that, but it is one.
From a UI perspective it would be nice if we could just choose the override and disable it - if not longer needed - by switching it off.
Both points are completely right, but you skipped the third action: Setting the override, which is a burden now. How often will you be setting an override compared to resetting one? This obviously well lean to the “set an override” side which you chose to ignore here
Although I am sympathetic to those who find the Properties panel burdensome, I find it hard to respond to this with much more than a shrug, I’m afraid. We’re comfortable with the design of the Properties panel, at least as far as the setting and unsetting of property overrides goes. I agree that it would be nice if the hit target for activating a property were the whole label rather than only the slide switch control, and we’ll try to do that at some point. In the future we also intend to make the Properties panel more keyboard accessible, which will hopefully help further.
This will be a welcome addition and likely render -some- of this conversation irrelevant.
I love how many functions can be assigned shortcuts (text or midi!) but there are a few functions that I would love to have added to the roster. As I do a ton of psalmody and modified chant, I hide stems nearly every day (and a lot of them). I’d love to be able to assign a shortcut to that function among others. If I can shortcut my favorite functions, the click UI of the properties panel will become a non-issue for me.
