-
-
Notifications
You must be signed in to change notification settings - Fork 654
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redesign profile handling in NVDA so users can lock / unlock them #17409
Comments
cc: @CyrilleB79, @XLTechie, @mltony, @Simon818, @rperez030, @pitermach, @TechHorseG, @Neurrone among people who would like this flexibility of deciding when global parameters and profileName.ini parameters are used. |
@Adriani90, Regarding your example with Firefox and speech rate. One more feature I wish could be included is to clear Firefox-specific speech rate and make it follow global speech rate once again without deleting Firefox profile. |
There are two requests here:
When following global configuration which would ofcourse work only on unlocked profiles, the settings changes on the global config would also be reflected in the Firefox profile ini file. |
Note: if the decision is to have context menu on profile items, I would still vote for the checkable list of lock / unlock profiles for efficiency reasons. It would be a mess to open the context menu on every of the 30 profiles to unlock them. |
@Adriani90 would that not essentially be the same as deleting the profile and starting again? If we don't tell NVDA which settings you want to follow the normal configuration, then that option would essentially be telling it to reset the configuration to the normal configuration. Personally, though more complex, I think the VO (and from memory Orca) solution of selecting categories to include in profiles makes the most sense. If a category is selected to be included, the any configuration from the profile in that category is used, otherwise the normal config values are used. If a category is excluded, the normal config is used. |
Not really, deleting a profile means you start really from scratch. Following the global configuration would practically happen only on a temporary basis, when you want to change just some settings but you don't want to focus three different applications.
To me this sounds too general and doesn't really meet users expectations which we saw in different issues related to profiles. Adding a whole category to a profile is far too much. Users need more flexibility to adjust single settings on a profile basis or on a global basis, and this should ideally happen on the fly, not being tied to a whole included or excluded category. Whereas the proposed UX would allow for a very quick lock / unlock feature and this allows more flexibility, especially when doing it via a key stroke. |
@Adriani90 how does your proposal address your point 2 "Firefox profile speech rate follows global speech rate"? I.e. how does the user tell NVDA that they want to delete speech rate from their firefox configuration permanently? |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Is your feature request related to a problem? Please describe.
Currently, changing settings in NVDA when more than one profile is created becomes complex, especially when more than 30 profiles are used. Settings have to be changed regularly on many profiles and this cannot happen at the same time so it's very inefficient.
In case of audio settings, e.g. the other apps volume adjuster does not work as expected, because the setting is profile dependent and so there is no way to change volume of all other apps except NVDA at once, because this has to be done on every profile for every application.
This problem is widely described in #17124 and the solution is currently not fully solving #16052, leading to wrong explanations in the user guide.
Other settings that are problematic with the current profile approach are e.g. the speech rate which often needs to be changed only temporarily, but sometimes also on a global scale and not on a profile scale.
Also ther are valid use cases when screen curtain should remian global and there are use cases when it should be profile based (see #10476 for more details).
Describe the solution you'd like
In #10156 the community came to the conclusion that introducing a lock/unlock feature to every profile is the best solution and easiest to implement. Locking a profile means the parameter written to the profileName.ini cannot be changed anymore and there is nothing else written to the profileName.ini, but to the global configuration instead.
User story:
By default all profiles are locked / all checkboxes in the checkable list are enabled, meaning that settings changes are always global) The parameter of the settings are not written to the profileName.ini file.
Conclusion: on locked profiles, NVDA would use a combiation of settings parameters written to the profileName.ini file before, and the remaining global settings parameters which are not written to the profileName.ini file.
Problem: What happens when users focused e.g. Firefox and changed a setting (e.g. speech rate) on its profile which was unlocked before, and change that setting again after the profile was locked? In that case we would have two speech rate settings parameters, one on the global configuration and one in the Firefox profile.
Does NVDA prefer the global setting? Or does the parameter which was written to the profileName.ini prevail?
My suggestion to the problem above is:
Describe alternatives you've considered
None
Additional context
This feature would introduce the risk that users get confused because some of their settings are changed after an NVDA update since the profiles get locked (e.g. if they changed the speech rate both on a profile and in the global configuration).
However, this is not a big problem, users would just have to unlock their profiles in the profile manager dialog manually, or via keystroke, and the previous behavior is restored.
The text was updated successfully, but these errors were encountered: