Consider changing or unbinding default application volume adjustment gestures

[codeofdusk]

The default gestures (NVDA+Alt+Pgup/Pgdn) for the application volume adjustment feature conflict with the popular NVDA Remote add-on. Especially since the feature is off by default, it might be worth leaving these gestures unbound.

Probably blocking #4390.

CC @mltony.

[CyrilleB79]

I am not a user of NVDA remote. Could you explain what do NVDA+alt+pageUp/pageDown in this add-on.

Generally, NVDA gestures take priority and add-ons need to adapt.

In the specific case of NVDA remote though, NV Access may consider that NVDA remote is quite popular and may put an option on some gestures if they intend to integrate it in core.

On the other side, I expect the other app volume commands to become a popular feature too. I was advocating for it to be enabled by default; though it has been decided the other way around to avoid potential issue with other external audio processing. Also, using gestures including pgUp/pgDown or arrows for volume commands is something quite natural and easy to remember for a volume.

If NV Access agrees to change the other app volume gestures, I'd ask at least that:

• some other default gestures be defined, i.e. do not just unbound these gestures
• the gestures be as suitable as the ones they are replacing for volume commands, i.e. using arrows or pgUp/pgDown as main key. I'd even prefer to stick with pgUp/pgDown, because of the third command to mute other apps using delete, which is in the same block as pgUp/pgDown.

In case NV Access accepts / wants to change these gestures, have you a proposal?

Could we use shift+alt+pgUp/pgDown as a replacement? As well as alt+shift+delete for "mute other apps"?

[Adriani90]

The alt+shift gestures would be in conflict with some other third party software. I don‘t think we should change the current gestures. Addons have to adapt in this case. Have you written to the addon authors?
I am closing as wont fix. This is what we did in similar cases before.

[XLTechie]

@Adriani90 Normally I agree with what you said, but in this case not. If NV Access plans to adopt remote into core (and I believe it is in the roadmap), then this issue is not just the standard add-on gesture vs. NVDA gesture debate. Should be re-opened.

[CyrilleB79]

As @XLTechie, I'd like to hear NV Access opinion, given the specificity of the current issue, i.e. because of the potential future inclusion of NVDA Remote in core.

So let's reopen until NV Access has clarified this point.

Regarding alternative gestures, you are completely right mentioning potential conflicts with native application shortcuts.
As a new alternative I'd rather suggest

• NVDA+alt+shift+pgUp/pgDown/delete: better than no gesture at all, even if a 4-key gesture is less comfortable than a 3-key one.
• Or NVDA+windows+pgUp/pgDown/delete: using Windows key would be quite relevant in this case since we deal with sound config outside NVDA.

Note that even if I give some alternative suggestions, I am not sure at all that changing these gestures is a good idea at all.

From what I have seen in the add-on, the conflicting gestures in NVDA remote are used to open a dialog to start a new remote connection or close a connection. These actions are also provided in NVDA's menu by the add-on.

IMO, it's more useful to be able to control the other apps volume quickly, thus having a shortcut, rather than opening a dialog to connect remotely or to quickly end a remote connection given the availability of such actions in NVDA's menu.

[codeofdusk]

Given that:

• Multiple default gestures are proposed
• This feature is disabled by default
• This feature will probably only be used by advanced users or in specialized use cases where standard audio ducking is insufficient

I propose that:

• We remove default gesture bindings for this feature
• In place of an option in settings, we enable volume adjustment if one or more of the volume-related scripts have bindings
  • This can be checked in a helper method in audio.appsVolume where needed (i.e. in initialize/terminate)
  • For each script, if volume handling isn't initialized yet (because a gesture was set during this run of NVDA), call initialize when needed.

[Adriani90]

Many users in german community are using this feature and are already used to the current gesture. Disabling the gesture completely is not a good option imho.The setting combo box is helpful as well, there is no reason why we should get rid of it, that would be inconsistent with e.g. audio ducking which can be also set either via gesture or via combo box.You should really try to contact the add-on author of the remote add-on first. It should be really a matter of minutes to change the coresponding gesture from that side.Von meinem iPhone gesendetAm 15.10.2024 um 00:34 schrieb Bill Dengler ***@***.***>: Given that: Multiple default gestures are proposed This feature is disabled by default This feature will probably only be used by advanced users or in specialized use cases where standard audio ducking is insufficient I propose that: We remove default gesture bindings for this feature In place of an option in settings, we enable volume adjustment if one or more of the volume-related scripts have bindings This can be checked in a helper method in audio.appsVolume where needed (i.e. in initialize/terminate) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[CyrilleB79]

@codeofdusk wrote:

This feature will probably only be used by advanced users or in specialized use cases where standard audio ducking is insufficient

This is a wrong assumption:

• There is already a lot of people that use such feature through add-on
• The case where audio ducking is insufficient is quite common: just go to Youtube and listen to the ad sound/volume that covers NVDA's speaking

Thus I strongly disagree with unbounding app volume adjustment commands.

Thus for best UX, either NVDA remote or app volume adjustment commands should be modified.

Regarding frequency of use:

• It seems to me that using such app volume/mute command is a much more common use case than NVDA remote's one
• For users of both NVDA remote and volume/mute commands of other apps, I expect the volume/mute command to be used more frequently than connect/disconnect.

If app volume/mute adjustment commands had to be changed, as expressed before, I'd ask that pgUp/pgDown/mute be still used. E.g. NVDA+windows+pgUp/pgDown/delete.

[XLTechie]

@CyrilleB79

* The case where audio ducking is insufficient is quite common: just go to Youtube and listen to the ad sound/volume that covers NVDA's speaking

I am surprised by this. I usually run with audio ducking disabled, because the ducking is too far for my taste. But Youtube is one of the few places I do use it, for the very reason that it is effective when using NVDA over ads and other such loudnesses. Maybe I just have my browser volume in Windows Sound Mixer set to a more reasonable level? I don't know, but what you described is exactly what ducking is for.

[amirsol81]

I vote against removing or altering the assigned volume-related key strokes. They are quite useful, and add-on owners should alter their key strokes when a set key stroke gets incorporated into NVDA core.

[CyrilleB79]

@seanbudd or @SaschaCowley would NV Access like to give their opinion on this?

If the issue should just be closed (my personal opinion), please confirm this / close it. If the issue is considered valid, it would be worth adding it in 2025.1.

[codeofdusk]

Also CC @michaelDCurran

[seanbudd]

We are in favour of unbinding these gestures

[Adriani90]

Not hat the community expects though.I am in favor of closing this issue to be honnest. People have already a muscle memory regarding these keystrokes, unbinding them is not an option at this stage in my view.Von meinem iPhone gesendetAm 22.10.2024 um 01:22 schrieb Sean Budd ***@***.***>: We are in favour of unbinding these gestures —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[XLTechie]

@Adriani90 wrote:

People have already a muscle memory regarding these keystrokes,

Surely not many people--it's only an alpha feature, after all. The point of alpha and beta features, is to test them, and see what works, and what doesn't.

unbinding them is not an option at this stage in my view.

Of course it is. They can be easily re-bound by anyone who wants them.

[ChrisDuffley]

@Adriani90: @XLTechie is right:

Of course it is. They can be easily re-bound by anyone who wants them.

Totally agree with everything you said. I personally changed the Connect/Disconnect gestures anyway, so these would work perfectly for me. I'm also not against NV Access's decision of unbinding these.

[Adriani90]

Sorry I thought this feature made it to the rc channel, but if this is not the case unbinding is ofcourse still an option.Von meinem iPhone gesendetAm 22.10.2024 um 07:45 schrieb Christopher Duffley ***@***.***>: @Adriani90: @XLTechie is right: Of course it is. They can be easily re-bound by anyone who wants them. Totally agree with everything you said. I personally changed the Connect/Disconnect gestures anyway, so these would work perfectly for me. I'm also not against NV Access's decision of unbinding these. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[CyrilleB79]

We are in favour of unbinding these gestures

@seanbudd, I am a bit surprised with this decision. Could you be more specific? There have been many arguments in this thread in favor of keeping these gestures (or defining other ones) and the support of the majority of the user to have these gestures. Have you read all the messages? I can make a summary later today with pros and cons if needed.

[Adriani90]

In fact, whether unbinding a gesture or not should be decided during a PR review, or shortly after merging. This feature is in the core for a while now, and the discussion loop was really long during the PR review. No one brought this issue at that time.

[codeofdusk]

Given that #17335 was rejected and the "enabled/disabled" setting should stand, I think it makes sense to consider new default bindings for these gestures.