Open Adriani90 opened 1 week ago
cc: @mltony
It's hard to say which behaviour is desired - you may want a situation where applications change whether or not this is enabled. We'd like to hear more from the community before making a decision.
@seanbudd could elaborate what you mean exactly? I mean the feature as such is defined as adjusting volume of all applications other than NVDA. However as per current implementation this doesn‘t work as long as it is profile dependent. It‘s just confusing as it is now.
So community feedback seems required in this logic, let's start a new feedback loop on this because the feature is really not working as expected. cc: @CyrilleB79, @XLTechie, @LeonarddeR, @ABuffEr maybe you have some thoughts on this as well. We really have to make sure feature are doing what they should before merging. This had already a very long feedback loop and it was from the beginning actually clear that it shouldn't be profile dependent.
There is clearly an issue described in this ticket and the current experience is not satisfactory.
Though we can discuss if making this parameter profile independent is the most desirable solution to the issue described here.
My personal opinion is that making application volume adjuster profile independent helps clarifying the UX. It avoids to have to answer to questions such as:
If someone has a real-life use case for a profile dependent configuration of the volume adjuster, I'd like them to describe it in details.
The follow-up question if we make volume adjuster profile independent is: should other apps volume and mute other apps parameters also be profile independent? I'd say yes for clarity again.
I was going to comment on this earlier, to say that I agree with @Adriani90 and now also @CyrilleB79.
I hesitated, because I was thinking about what @seanbudd implied. But I just can't figure why someone would only want this feature in a subset of apps, or why we should expect that to be a valid use case.
IMO, we are really getting outside the territory of something a screen reader should be responsible for. Which is close to what I've thought about this feature all along anyway.
That said, I'm not the target audience for this, so the value of my opinion is limited. But if I had to go one way or the other, I would vote for not allowing profiles to change it, as it just muddles the UX, and would be a nightmare for people who offer support.
These opinions apply to the system-wide audio features in general, as @CyrilleB79 mentioned.
Steps to reproduce:
Actual behavior:
Expected behavior:
The application volume adjuster should not be profile dependend in order to avoid these issues. Also it is confusing to describe the setting as "it adjusts the volume of all applications other than NVDA". In this case this is not true because it depends on whether you enabled the applications volume adjuster for all your profiles or not.
NVDA logs, crash dumps and other attachments:
n/a
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
last alpha
Windows version:
Windows 11 23 H2
Name and version of other software in use when reproducing the issue:
Any application with a NVDA profile
Other information about your system:
n/a
Other questions
Does the issue still occur after restarting your computer?
yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
no
If NVDA add-ons are disabled, is your problem still occurring?
yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
n/a