Redesign profile handling in NVDA so users can lock / unlock them

[Adriani90]

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:

1. A user created 10 profiles
2. A user wants to change the speech rate globally
3. The user wants to change reporting of elements in document formating settings globally
4. The user wants to change table related reportings in document formating settings for a profile only.
5. The user want to use the applications volume adjuster and the sound split feature globally as this is the best user experience and coresponds to the descriptions in the user guide.
6. The user wants to change punctuation level on a profile only
7. The user want to change the synthesizer voice on 2 of the 10 profiles
8. The user wants to enable screen curtain globally accross all profiles
9. The user opens the profile manager after 10 profiles are created
10. In addition to the current list of profiles status, an additional checkable list is displayed (e.g. lock / unlock profiles list) in which every profile item name is preceeded by the string "lock" and can be enabled via its checkbox. E.G. the profile items in this checkable list would look like:

• Lock firefox profile checkbox checked
• Lock WinWord profile checkbox checked
• Lock Outlook profile checkbox checked

11. 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.
12. The user unlocks some profiles by disabling the coresponding profile check boxes.
13. From now on, every setting that the user changes is only applied for the unlocked profiles and the parameter is written to the profileName.ini files of the unlocked profiles.
14. The user can lock the profiles again as soon as the changes have been done, and the coresponding profileName.ini files become protected.

Advantage: the checkable list allows for bulk writing parameters on multiple profile ini files at the same time.

Problems

1. What happens when the user changes a setting on locked profiles?

Suggestion

• If that setting is already part of the profile ini file, do not allow to change (e.g. a warning message saying "setting cannot be changed for this profile, the profile x is locked" when pressing the keystroke (e.g. nvda+2). In the settings dialogs, the coresponding settings which are part of the ini files of locked profiles should be unavailable.
• At the same time, provide a keystroke to unlock the currently focused profile (e.g. nvda+shift+p) and a keystroke to unlock all profiles at once (nvda+ctrl+shift+p), in order for the settings to become available again for those unlocked profiles. This would allow users to manage settings on the fly.

2. What happens when a user is not keen with the speech rate of one or more profile ini files?

suggestion

• It should be possible to make the profiles follo / unfollow the global config (e.g. from the context menu of each profile in the profile manager dialog).
• Changing the speech rate in global config would imediately reflect in the profile ini files as well. This approach allows for bulk adjusting profile ini files at once, making them in sync with the global config.

Describe alternatives you've considered

Value based locking feature

While the proposed solution above is focused on adding settings parameters to the profile ini files when they are unlocked, the alternative would be a value based locking feature:

• When profile ini is locked, settings parameters can be added but their values are not saved when the users change tem, still they impact the profile ini file.
• It would need a combo box for every profile to specify when the setting should be saved when the profile is locked (e.g. after NVDA restart).
• When profile ini file is unlocked, changed values are saved in the profile ini file according to the coresponding setting in general settings category (e.g. after NVDA exit).

Drawbacks:

• settings are not saved anywhere when profiles are locked and they revert every time you change window with alt+tab which would cause confusions.
• The UX would need a much more complex development because you have to define a combo box for every profile to decide when its settings values should be saved as long as it is locked.

Including or excluding whole settings categories to profiles (same as VO or Orca)

This would allow for every profile to include or exclude settings categories, .g. via a checkable list in the profile dialog. This means every setting changed in the included category (e.g. braille settings) would go into the profile ini file when focusing the app with the profile triggered. When the category is excluded, changing settings in the coresponding category would be saved only in the global config.

Drawbacks:

• Higher development efforts needed, because categories of settings in settings pannel would have to be in sync with what users include and exclude in or from profiles in the profile manager.
• It is not really possible to communicate which profiles a settings category will affect when focusing the category in the settings pannel, so it will become intransparent which categories go in which profiles (especially when you have 30 profiles)
• The profiles ini files become inefficiently leaked with settings categories where only one setting is regularly changed on a profile basis.

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.

Additional things to consider when implementing this:

• When a profile is locked, and an user opens the settings pannel while focusing an app with that locked profile (e.g. firefox) the Firefox profile should not be announced on the settings category, because settings parameters and their values are not impacting that profile while it is locked.
• Instead, NVDA should announce "global profile" or something similar.

[Adriani90]

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.

[mltony]

@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.
This would be useful when you happen to have adjusted speech rate in Firefox by mistake. In my understanding once this happens - there is no easy way to revert to global speech rate for Firefox - but correct me if I'm wrong. Currently you would have to either drop the entire Firefox profile or manually edit ini files, which is way too tedious. I wish there was an easier way, but I am struggling to come up with a good UX concept for this feature that would be user-friendly.

[Adriani90]

One more feature I wish could be included is to clear Firefox-specific speech rate
This would be useful when you happen to have adjusted speech rate in Firefox by mistake. In my understanding once this happens - there is no easy way to revert to global speech rate for Firefox.

There are two requests here:

1. Reverting speech rate because you changed it accidentally
   Solution: if you didn't restart NVDA or you didn't save by pressing nvda+ctrl+c, then you can revert to the lastly saved setting by pressing ctrl+nvda+r, so the speech rate resumes to the value when you saved it for the last time. This should solve your issue actually. But yeah, if you want to make sure that only the speech rate is resumed, then have a look at Add temporary speech rate setting #16431, Jaws provides this already. The speech rate resumes as soon as you change the window and return back to it.

2. Firefox profile speech rate follows global speech rate
   Solution: We have currently a list of profiles in the profile manager, this could be changed to a list similar to the addon store where every profile item would have a context menu. When opening the context menu of a profile item, following menu items could be available:

• Follow global configuration (becombes "unfollow global configuration when following it). It is only available for unlocked profiles.
• Mannualy activate
• Rename
• Delete

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.

[Adriani90]

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.

[SaschaCowley]

@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.

[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.

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.
In my suggestion you could open the context menu of 3 different profiles, choose to follow the global configuration, and you change the global configuration while this would reflect on three profiles at the same time. This is very efficient way of profile handling compared to what we have now or compared to VO or Orca. If you unfollow the global config, then the profiles are handled separately again.

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.

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.
The UX in VO and Orca is not satisfactory at least in my view, because you have to cope with lots of including and excluding activities.

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.

[SaschaCowley]

@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?

[seanbudd]

Converted to a discussion until a more clear UX is resolved

[Simon818]

My suggestion for this (which I still believe to be the simplest):

• Profiles can indeed be unlocked or unlocked, and a profile is unlocked by default.
• When a profile is unlocked, any settings that are changed while that profile is active will be saved to that profile. That means new parameters will make their way into the INI file.
• When a profile is locked, those parameters can still be adjusted in the profile but any new parameters are not saved to the profile.
• For instance, I have a text adventure game profile that increases speech rate from 75 to 85, turns off typing interrupt, and sets punctuation to "none".
• Once I've created that profile, if I lock it, changing the speech rate in my game window will still permanently change the speech rate for the text adventure profile.
• Changing speech pitch, output device, or Braille settings in the game window will change them globally since those settings were never made part of the text adventure profile before it is locked.

Here are some other proposals and why I don't think they'll work as well:

• Locking the profile should lock it completely so no settings can be changed:
  • This will cause settings changes to be unexpectedly thrown away. If you lock the game profile and you change a setting, that setting will never get saved anywhere and will revert after switching back into the window, JAWS-style. I think this is much more confusing, though I'll admit it would be easier to code.
• You should be able to choose settings categories that will apply to each profile:
  • I don't want to have to think about where a setting is in order to add it to my profile. I don't want to have to choose. I just want to change the settings and decide when I've changed enough of them.
  • If I change a setting that happens to be a part of the same category that's already in the profile, and the profile is active, it will still "leak" into the profile permanently--in other words, the same problem as we're trying to solve, but on a smaller scale.
  • There's no guarantee the settings someone wants to change will be in the same one or two categories. Maybe you want a profile with five unique settings and they're in five categories. Now that's five times the potential settings leakage and we've barely solved the problem being discussed.
  • Big important settings like the current Braille display, current synthesizer, and current audio device could easily leak into the profile if the right categories are selected. This can result in really confusing scenarios where someone's primary output method is suddenly not working because they inadvertently changed it while the profile was active and then switched out of the window. This exact thing happens to me constantly because I switch between Braille displays and audio output devices.

[Adriani90]

@SaschaCowley wrote:

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?

Profile speech rate follows global config speech rate should not allow for deleting the speech rate from profile ini file, this is indeed not possible on global config as well unless you delete the ini file as you pointed out. But @mltony doesn't really want to delete the speech rate from the profile ini file, he does it because there is no other way to resume speech rate. Resuming speech rate is covered by point 1 above (temporary speech rate setting as proposed in #16431). Point 2 is another request and is actually tackling rather other problems but not particulary the one about resuming speech rate.

@Simon818 thanks for your feedback, let's try to avoide repeating what is already described and discuss on point what we agree on or what we don't agree on. You wrote:

a profile is unlocked by default.

I proposed profiles to be locked by default given our experience in the community that people more often change settings on a global basis tahn on a profile basis. And this was also what was agreed on in #10156. I still think this would make sense.

When a profile is unlocked, any settings that are changed while that profile is active will be saved to that profile. That means new parameters will make their way into the INI file.

That's what I described in the initial description.

When a profile is locked, those parameters can still be adjusted in the profile

I don't really agree with this, because the settings would then restore everytime you leave the window with alt+tab and that would rather cause confusions. I think saving them in the global config instead is a better option and according to my understanding was also agreed upon in #10156.

• For instance, I have a text adventure game profile that increases speech rate from 75 to 85, turns off typing interrupt, and sets punctuation to "none".
• Once I've created that profile, if I lock it, changing the speech rate in my game window will still permanently change the speech rate for the text adventure profile.

This would cause the problem of settings being resumed to easily. While this makes sense for speech rate as explained in #16431, other settings should not be resumed that quick when changing windows with alt+tab or so (e.g. changing audio output). That's why the only way is to save them into the global config when the profile is locked.
But yeah it is ofcourse debatable whether all settings should be temporary for the locked profile, that is they would always resume to the state when the profile was locked after you change the window to another application and return back. But then it is confusing when you have 10 profiles and would like to change speech rate globally. The easiest way is to lock all 10 profiles and change the speech rate globally. You only need to unlock the profiles from time to time when you want to adjust some settings.

• Changing speech pitch, output device, or Braille settings in the game window will change them globally since those settings were never made part of the text adventure profile before it is locked.

That's what I've also described in the initial description above.

• Locking the profile should lock it completely so no settings can be changed

That's what has been agreed on in #10156 for the profile ini file.

◦ This will cause settings changes to be unexpectedly thrown away.

Not really, they are then saved to the global config.

◦ I don't want to have to think about where a setting is in order to add it to my profile. I don't want to have to choose. I just want to change the settings and decide when I've changed enough of them.

You would have to think about it too when you add whole categories to the profile, and the UX would get more complex and not really manageable. What you say is already possible with the lock feature. When you decide there were enough settings changed for that profile, you just lock it. That's what was agreed on in #10156.
If I add 3 categories to the firefox profile, but I change only one setting of those categories on a regular basis, what is the point of it? I will forget anyway after a while that I added 3 categories on that profile. I rather think that in Firefox I often don't need tables to be announced, so that's quite clear that this is definitely the setting I change on a profile basis regularly.

If I change a setting that happens to be a part of the same category that's already in the profile, and the profile is active, it will still "leak" into the profile permanently--in other words, the same problem as we're trying to solve, but on a smaller scale.

What do you mean by smaller scale? Actually the categories proposal is on a bigger scale, and then the profile ini file is always leaked with categories where you might never change a setting on a profile basis.
I still think the lock / unlock feature based on settings parameters is a UX that's good enough to cover all the problems described above.

◦ There's no guarantee the settings someone wants to change will be in the same one or two categories. Maybe you want a profile with five unique settings and they're in five categories.

Exactly that's why leaking profile ini files with whole categories is inefficient.

Now that's five times the potential settings leakage and we've barely solved the problem being discussed.

I don't understand this part. If I have 5 settings which I change on the unlocked profile ini file, why are they 5 times leaked in there? The proposal is to ad the coresponding settings parameters once to the unlocked profile when I change them on that profile for the first time. Their values are then adjusted accordingly when I change them on the unlocked profile afterwards.

◦ Big important settings like the current Braille display, current synthesizer, and current audio device could easily leak into the profile if the right categories are selected. This can result in really confusing scenarios where someone's primary output method is suddenly not working because they inadvertently changed it while the profile was active and then switched out of the window. This exact thing happens to me constantly because I switch between Braille displays and audio output devices.

So it seems you are not keen on adding whole categories to the profile ini file in the end. These confusions is what I was trying to explain above as well. If you add the whole category to a profile, such things can occur very often.

[SaschaCowley]

@Adriani90 wrote:

Profile speech rate follows global config speech rate should not allow for deleting the speech rate from profile ini file, this is indeed not possible on global config as well unless you delete the ini file as you pointed out. But @mltony doesn't really want to delete the speech rate from the profile ini file, he does it because there is no other way to resume speech rate. Resuming speech rate is covered by point 1 above (temporary speech rate setting as proposed in #16431). Point 2 is another request and is actually tackling rather other problems but not particulary the one about resuming speech rate.

I think one of us is misunderstanding the other here, so let me try laying out a situation that I'm imagining so we can work out where the misunderstanding is coming in.

1. I have my NVDA set up exactly the way I like it for daily use, but I discover that this configuration is not very good for proof-reading documents. As a result, I decide to create a proofing configuration profile.
2. I make adjustments to this profile to settings such as punctuation reporting, reporting font attributes, and speech rate. I then save the profile configuration, and lock the profile.
3. Later on, I find that I don't actually need a different speech rate when proofing, I just need the altered punctuation and document formatting settings. My options are:
   • Manually change the speech rate in my proofing profile. If my speech rate preference changes (say I'm somewhere loud so I need slower speech, or I get more used to the voice I use so can understand quicker speech) I will keep on having to manually adjust the speech rate because it won't be synchronised across the normal and proofing profiles.
   • Set the proofing profile to follow the normal profile. At this point I have erased all the work I've put in to getting my proofing profile just right (except for one setting), so I might as well just delete my proofing profile and start again. This is arguably no better than what we already have.

My suggestion for how to fix this is similar in spirit to yours, so perhaps it is already what you are suggesting and I misunderstand you:

• Offer a context menu on each profile, which contains a list of settings in that profile. Under each setting, offer a "revert to normal configuration" option, and a "remove from profile" option.
• Alternatively, just have a "settings in this profile" item, which launches a window with all settings in this profile in a list box. Allow the user to delete options from this list with the del key or a button in the dialog, similar to the speech dictionary interface.

Essentially, what I'm saying is this: I like the parameter lock feature. I think it is a neat way of providing the desired functionality. However, I think it is incomplete without the ability to remove a parameter from a profile.

[Adriani90]

@SaschaCowley you wrote:

Set the proofing profile to follow the normal profile. At this point I have erased all the work I've put in to getting my proofing profile just right (except for one setting)

I think here is the point where our thoughts are different. In my mind, when activating (follow global profile", nothing happens until you change a setting in the global profile. In that moment, the setting you changed in the global profile, is imediately reflected in the profile ini file. All other settings are not impacted unless you change them manually in the global profile.
When you unfollow the global profile, the profile ini file becomes independent again.
So if I am not keen with the speech rate on the profile ini file

1. Follow the global profile
2. Adjust speech rate on the global profile once up and down (e.g. from synth settings ring).
   In that moment, the speech rate in the profile ini file is in sync with the global profile
3. Unfollow the global profile, so the profile ini file becomes independent

The advantage of the this approach is that I can do these steps on multiple profiles at the same time. Let's say I have 20 profiles, and on 6 of them I am not keen with the speech rate, then I make 6 profiles to follow the global profile, change the speech rate as needed on the global profile, and I have that reflected in 6 profile ini files at the same time.

I edited the initial description to make the UX clearer.

Alternatively, just have a "settings in this profile" item, which launches a window with all settings in this profile in a list box. Allow the user to delete options from this list with the del key or a button in the dialog, similar to the speech dictionary interface.

I think this approach is too inefficient and might become complex. Imagine that you could have situations where you have 20 profiles or more, and you would then have to do this on each profile. You could not manage multiple profiles at once.

So if we agree on follow / unfollow global config approach, I can create a separate feature request for that one.
I agree with you that this should be implemented together with the lock / unlock feature.

[Adriani90]

@SaschaCowley what is the purpose of deleting a settings parameter permanently from a profile ini file? If If that's done, then the global setting parameter would apply. This would also be the same when I choose "follow global profile" from the context menu of a profile, and change e.g. the speech rate on the global config afterwards. In that moment, the speech rate in the profile ini file would change, and I am still flexible enough to unfollow the global config and adjust the speech rate separately on a profile basis, that's the advantage of it.
Deleting the speech rate completely would probably result in adding it again when the user adjusts this setting again on a profile basis. In my view it is more efficient to adjust values back and forth instead of repeatedly adding or deleting the whole setting parameter. But maybe I am wrong.

[XLTechie]

@Adriani90 Respectfully, I do not find this to be an accurate summary of the community conclusion in #10156.

1. At no point, was it proposed to have a list of locked/unlocked profiles. It was universally stated that each profile, when chosen as active, should have a lock/unlock button.
2. There were two primary alternatives discussed in the latter half of the issue: a parameter lock, vs. a value lock.
   * In a value lock, as proposed by @CyrilleB79, after a user edits some parameters (e.g. speech rate, announce line numbers, synth selection), and locks the profile, no new parameters could be added to the profile, and no changes to the values of those parameters could be made.
   * In a parameter lock, as proposed by @Simon818, when locked, the values of already included parameters could still be changed, but no new parameters could be added.

Several difficulties exist with the value lock idea, as adequately stated by others in that issue (especially #10156 (comment)), that make the parameter lock be the preferred (and more user friendly), solution.

That is my reading of the issue--no locked profile list, and the statement of "there is nothing else written to the profileName.ini, but to the global configuration" is not representative of either of the main solutions discussed.
In the value lock idea, other value changes to parameters already in the profile, would have to remain unsaved, and so not written anywhere. In the parameter lock idea, they would be written to the profile.

Lastly, having profiles be locked at creation by default was never raised in the issue that I noticed, so shouldn't be part of the summarized solution. Nobody asked for that, and it seems contrary to the reason someone creates a profile.

The concern raised by @mltony is of course valid, but seems outside the scope of this issue. Issue drift is a big problem on this topic, because there are a lot of tangential problems associated with profiles. But IMO, that one should be its own issue.

[Adriani90]

Ok in this case the discussion seems to get stuck. I tried to summarize and interpret the points agreed on in principle, so that the underlying problems are solved in a user friendly way. It seems you rather expect a 100% summary of the old discussion. Please proceed with your version then, because this one is again blown up already and the arguments you raised are not really bringing this forward in a constructive way.Von meinem iPhone gesendetAm 20.11.2024 um 12:45 schrieb Luke Davis ***@***.***>: @Adriani90 Respectfully, I do not find this to be an accurate summary of the community conclusion in #10156. At no point, was it proposed to have a list of locked/unlocked profiles. It was universally stated that each profile, when chosen as active, should have a lock/unlock button. There were two primary alternatives discussed in the latter half of the issue: a parameter lock, vs. a value lock. * In a value lock, as proposed by @CyrilleB79, after a user edits some parameters (e.g. speech rate, announce line numbers, synth selection), and locks the profile, no new parameters could be added to the profile, and no changes to the values of those parameters could be made. * In a parameter lock, as proposed by @Simon818, when locked, the values of already included parameters could still be changed, but no new parameters could be added. Several difficulties exist with the value lock idea, as adequately stated by others in that issue (especially #10156 (comment)), that make the parameter lock be the preferred (and more user friendly), solution. That is my reading of the issue--no locked profile list, and the statement of "there is nothing else written to the profileName.ini, but to the global configuration" is not representative of either of the main solutions discussed. In the value lock idea, other value changes to parameters already in the profile, would have to remain unsaved. In the parameter lock idea, they would be written to the profile. Lastly, having profiles be locked at creation by default was never raised in the issue that I noticed, so shouldn't be part of the summarized solution. Nobody asked for that, and it seems contrary to the reason someone creates a profile. The concern raised by @mltony is of course valid, but seems outside the scope of this issue. Issue drift is a big problem on this topic, because there are a lot of tangential problems associated with profiles. But IMO, that one should be its own issue. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Adriani90]

By the way, whether a profile has a lock button or is a checkbox itself is really such a small point with no real effect on UX. I wonder why you want to open up the discussion again on such small things, but maybe there are arguments which speak for a button for each profile instead of a checkable list. If there are, please elaborate on the advantages of having a button for each profile and the disadvantage of the checkable list.Von meinem iPhone gesendetAm 20.11.2024 um 13:46 schrieb Adriani Botez ***@***.***>:Ok in this case the discussion seems to get stuck. I tried to summarize and interpret the points agreed on in principle, so that the underlying problems are solved in a user friendly way. It seems you rather expect a 100% summary of the old discussion. Please proceed with your version then, because this one is again blown up already and the arguments you raised are not really bringing this forward in a constructive way.Von meinem iPhone gesendetAm 20.11.2024 um 12:45 schrieb Luke Davis ***@***.***>: @Adriani90 Respectfully, I do not find this to be an accurate summary of the community conclusion in #10156. At no point, was it proposed to have a list of locked/unlocked profiles. It was universally stated that each profile, when chosen as active, should have a lock/unlock button. There were two primary alternatives discussed in the latter half of the issue: a parameter lock, vs. a value lock. * In a value lock, as proposed by @CyrilleB79, after a user edits some parameters (e.g. speech rate, announce line numbers, synth selection), and locks the profile, no new parameters could be added to the profile, and no changes to the values of those parameters could be made. * In a parameter lock, as proposed by @Simon818, when locked, the values of already included parameters could still be changed, but no new parameters could be added. Several difficulties exist with the value lock idea, as adequately stated by others in that issue (especially #10156 (comment)), that make the parameter lock be the preferred (and more user friendly), solution. That is my reading of the issue--no locked profile list, and the statement of "there is nothing else written to the profileName.ini, but to the global configuration" is not representative of either of the main solutions discussed. In the value lock idea, other value changes to parameters already in the profile, would have to remain unsaved. In the parameter lock idea, they would be written to the profile. Lastly, having profiles be locked at creation by default was never raised in the issue that I noticed, so shouldn't be part of the summarized solution. Nobody asked for that, and it seems contrary to the reason someone creates a profile. The concern raised by @mltony is of course valid, but seems outside the scope of this issue. Issue drift is a big problem on this topic, because there are a lot of tangential problems associated with profiles. But IMO, that one should be its own issue. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Adriani90]

@XLTechie wrote:

• In a value lock, as proposed by @CyrilleB79, after a user edits some parameters (e.g. speech rate, announce line numbers, synth selection), and locks the profile, no new parameters could be added to the profile, and no changes to the values of those parameters could be made.

This is not a feasible solution, and @CyrilleB79 as well as others agreed rather upon a parameter based solution which I proposed here. Things on which we didn't agree were not part of the request here. But I've added them all now to the alternatives part in the initial request.

[Adriani90]

@XLTechie wrote:

• In a parameter lock, as proposed by @Simon818, when locked, the values of already included parameters could still be changed, but no new parameters could be added.

Again this is what I've described above in the initial description.

[Adriani90]

the statement of "there is nothing else written to the profileName.ini, but to the global configuration" is not representative of either of the main solutions discussed.
In the value lock idea, other value changes to parameters already in the profile, would have to remain unsaved, and so not written anywhere. In the parameter lock idea, they would be written to the profile.
Lastly, having profiles be locked at creation by default was never raised in the issue that I noticed, so shouldn't be part of the summarized solution.

That's not true. In #10156 (comment)
and
#10156 (comment)
even you and also the other person both have the understanding that having settings not reflected in the profile ini when it is locked is the prefered solution. Letting all profiles unlocked by default would not reflect this. Your problem of users being confused is even described here in the additional context in the initial description.

Regarding saving them to global config when profile is locked, this is the only way to solve @Simon818 problem in #10156 (comment) having the proposed feature in mind. Otherwise his settings would be thrown away after pressing alt+tab, and this is definitely not the intended behavior.

[Adriani90]

@SaschaCowley I edit now the alternatives of the discussed things in the initial description, so NV Access can decide on a prefered UX design.
The points about cleaning profile ini file permanently vs. follow / unfollow global config can be discussed in another issue, as well as the issue about temporary speech rate setting which is better discussed in #16431.

[Simon818]

I think the parameter lock and the parameter removal/management are two separate issues, and both are things that would be useful. We already do not have a way to remove a parameter from a profile, so whether we add a parameter lock or not, that ability still doesn't exist. If anything, implementing a parameter lock would make this feature less necessary. That's not to say I don't think it should happen, but these two things can be developed relatively independently of each other and they are both separate enhancements that don't really affect each other. I don't think talking about it as part of a greater profile redesign is a bad idea, but I'm also conscious that it doesn't quite fit here.