accessibility.signalOptions.delays not user friendly

[isidorn]

Testing #213344

Right now the structure of accessibility.signalOptions.delays settings is sort of leaking your implementation. It has a complex structure, and because of that is not shown in the settings editor, but only in the settings.json.

Can we simplify the structure of this setting so the settings UI editor supports showing it?

[meganrogge]

what would you suggest? I don't think adding 9 settings would be a good idea

[isidorn]

Any simplification as long as it shows up in the settings UI.
One example:

Get rid of signalOptions. Get rid of volume. Then have:

accessibility.signals.debouncePositionChanges
accessibility.signals.delays

[meganrogge]

That's what we had originally and @hediet suggested we introduce signal options.

[hediet]

The reason why I suggested signalOptions was that it stands out from all the other signals.
If you have

• accessibility.signals.progress (signal)
• accessibility.signals.delays (setting for all signals)
• accessibility.signals.save (signal)
• ..., see

... it is very confusing which is a signal and which is a signal setting. It's like hiding the needle in the haystack.

[isidorn]

Good point. So with your suggestion we are optimizing for settings.json users, and we are failing those that use the settings UI. Since the settings UI is the default experience my suggestion is to optimize for that.

Though I have no strong feeling either way.

[hediet]

I think the settings UI sorts alphabetically as well. So if we'd mix the settings with the signals, it would be confusing there as well.

Imagine if there are 3 interesting settings somewhere in this list of 29 audio cues:

---

We should just make sure Signal Options is editable in the settings editor:

[meganrogge]

@rzhao271 is there a way we can do that?

vscode/src/vs/workbench/contrib/accessibility/browser/accessibilityConfiguration.ts

Lines 174 to 188 in 7ed5156

	'accessibility.signalOptions': {
	type: 'object',
	additionalProperties: false,
	properties: {
	'volume': {
	'description': localize('accessibility.signalOptions.volume', "The volume of the sounds in percent (0-100)."),
	'type': 'number',
	'minimum': 0,
	'maximum': 100,
	'default': 70,
	},
	'debouncePositionChanges': {
	'description': localize('accessibility.signalOptions.debouncePositionChanges', "Whether or not position changes should be debounced"),
	'type': 'boolean',
	'default': false,

[rzhao271]

There's currently no support in the Settings editor for objects where the values could also be objects, even if the total object is just two levels deep.

[meganrogge]

We should either close this as designed or go back to the many settings vs this object. Which do you think @hediet ?

[isidorn]

Both options work for me.

[meganrogge]

Another argument for destructuring is when I search for debounce, debouncePositionChanges doesn't even show up 🐛

[hediet]

Yes, we should destructure the object! But keep the namespace "signalOptions", e.g. "accessibility.signalOptions.delays", ....

[meganrogge]

verify that all of the accessibility.signalOptions.* settings work and are user friendly. Also verify that if you have settings of the old structure and reload the window, they get migrated correctly.

[isidorn]

This works better now, thank you! Adding verified label.