search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.12k stars 638 forks source link

Settings should be removed from configuration profiles when equal to normal configuration #4892

Open nvaccessAuto opened 9 years ago

nvaccessAuto commented 9 years ago

Reported by leonarddr on 2015-02-06 11:10 By default, when a configuration profile is created, the configuration file is empty. As soon as a setting is changed in the profile, the setting is defined in the profile's configuration file. For example, when nvda.ini contains,

[speech]
    synth = vocalizer_expressive

and i change the speech in the profile to espeak, the configuration file contains the espeak synth as expected. However, when changing the synth in the profile back to vocalizer_expressive, we have a duplicate: Both nvda.ini and profile.ini contain synth = vocalizer_expressive. This means that, when changing the normal configuration's synth to espeak, the profile.ini and nvda.ini differ and you will have to set the synth to espeak in both profile and normal configuration. This is quite annoying and leads to unexpected situations. Also, it might be the underlying idea behind ticket #4167. Therefore, when a profile setting is changed, NVDA should check against the normal configuration whether the change is equal to it. So, when vocalizer_expressive is defined in the normal configuration and the synth is changed in the profile from espeak to vocalizer_expressive, NVDA should detect that this change reverts the synth setting to the normal configuration and should remove the synth parameter from the profile.

nvaccessAuto commented 9 years ago

Comment 1 by jteh on 2015-02-06 11:24 The flip side of this is that if the user makes an explicit change in the profile, they can currently expect this to be saved, regardless of the normal configuration; i.e. this is documented and consistent behaviour. If they then change their normal configuration, they might still expect that setting to remain as is in the profile because they made the change explicitly. Doing as you suggest requires the user to know what is in their default configuration to know what will stick and what won't.

nvaccessAuto commented 9 years ago

Comment 2 by leonarddr on 2015-02-06 13:39 I understant. However, in the current situation it isn't possible to restore a changed setting in a profile to the normal configuration's default. This starts being annoying when temprorarily changing the synthesizer or braille display as mentioned in my proposal. As soon as you once explicitly change your synthesizer in a profile and restore it to the normal configuration's synthesizer, you will always have to change the synth separately for the profile. That's probably why #4167 is suggested. I have one text editing profile and had to manually delete some garbage from the configuration file like synth and braille display. So, i still vote for my suggestion as an optional solution. This could be accomplished by adding an option to the general settings for switching between current and proposed behavior.

nvaccessAuto commented 9 years ago

Comment 3 by bdorer (in reply to comment description) on 2015-03-01 17:15 I vote against that because profile systemis complex enugh for most users. So this shouldn't be made automaticly by nvda. May it's possible to see which options has been changed in a profile and delete them manually. This has the advantage that Users are able to see what they changed in each profile.

LeonarddeR commented 8 years ago

May it's possible to see which options has been changed in a profile and delete them manually. This has the advantage that Users are able to see what they changed in each profile.

Coming back to this, I really like this approach. It however might be quite difficult to realise because of the multiple settings dialogs NVDA now uses. An other approach could be:

LeonarddeR commented 8 years ago

Coming back to this, I really like this approach. It however might be quite difficult to realise because of the multiple settings dialogs NVDA now uses.

Actually, it might be an option to create a new dialog for this and gather all the changed configuration options based on how rapid settings does this.

LeonarddeR commented 8 years ago

I've been working on the latter suggestion, but I'm afraid it needs a whole bunch of changes. Most importantly, it should be possible to map a WX control to a particular setting in config.conf. For example, when we have self.languageList=wx.Choice(self,languageListID,name=_("Language"),choices=[x[1] for x in self.languageNames]), we should be able to retrieve from the control that it controls config.conf["general"]["language"]. When that's possible, we can gather the controls from every settings ddialog in a similar way Rapid Settings does it, checking whether the setting it controls differs from its value in the normal configuration.

of course, it can be solved by using two instances for every settings dialog, one instance for the normal configuration and one instance for the profile configuration, but that's overwhelmingly ugly.

derekriemer commented 8 years ago

@jcsteh mind if I take this one?

jcsteh commented 8 years ago

I'm not really a big fan of having a dialog with a list of changed settings. Aside from anything else, it's not enough to just check config values and revert the config value if the user wants to remove it.

I wonder whether we can mitigate the need for this altogether by allowing users to restrict a profile to specific groups of settings (config sections).

Anyway, please hold on this for now. I think we need to have a bit of a brainstorm on this internally.

LeonarddeR commented 8 years ago

I wonder whether we can mitigate the need for this altogether by allowing users to restrict a profile to specific groups of settings (config sections).

That's an idea I certainly like!

derekriemer commented 8 years ago

Another thing to toss around internally might be ability to lock a profile so that it can't be changed unless edit profile is selected.

On 10/18/2016 1:13 AM, Leonard de Ruijter wrote:

I wonder whether we can mitigate the need for this altogether by allowing users to restrict a profile to specific groups of settings (config sections).

That's an idea I certainly like!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/4892#issuecomment-254425791, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivX-lBQ0Rutd_k4dBOyljxLvS-5hfks5q1HGngaJpZM4JESVm.

Derek Riemer

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu Phone: (303) 906-2194

jcsteh commented 8 years ago

In the initial version of this code, you had to explicitly edit a profile to change setings, effectively locking profiles by default. However, users complained because they would switch to their app, make a change and it wouldn't be remembered. Alternatively, they'd edit the profile and forget to deactivate it, so all changes got applied to the profile being edited. Either way, I think we're going to confuse some group of users.

derekriemer commented 8 years ago

The thing is with this method, if I use the synth settings ring to turn my computers volume up because my niece is crying next door for example, I can't easily tell NVDA to ignore that, so the configuration profile is in effect corrupted. This would be an explicit option, for example you'd check a box that says lock this profile from further edits, at least in the way I imagine it.

Either way,, over time, profiles become corrupted without intention here. Hope this helps clarify the confusion over this. On 10/18/2016 4:31 AM, James Teh wrote:

In the initial version of this code, you had to explicitly edit a profile to change setings, effectively locking profiles by default. However, users complained because they would switch to their app, make a change and it wouldn't be remembered. Alternatively, they'd edit the profile and forget to deactivate it, so all changes got applied to the profile being edited. Either way, I think we're going to confuse some group of users.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/4892#issuecomment-254469233, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivUQC7BvoNkSP34SIJnDauDsnt5Bgks5q1J_qgaJpZM4JESVm.

Derek Riemer

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu Phone: (303) 906-2194

derekriemer commented 8 years ago

==Note that I'm just trying to provide use cases where the current behavior is anti-productive or annoying, and I totally understand the other side of this issue as well. This isn't something that can just be fixed.

On 10/18/2016 4:31 AM, James Teh wrote:

In the initial version of this code, you had to explicitly edit a profile to change setings, effectively locking profiles by default. However, users complained because they would switch to their app, make a change and it wouldn't be remembered. Alternatively, they'd edit the profile and forget to deactivate it, so all changes got applied to the profile being edited. Either way, I think we're going to confuse some group of users.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/4892#issuecomment-254469233, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivUQC7BvoNkSP34SIJnDauDsnt5Bgks5q1J_qgaJpZM4JESVm.

Derek Riemer

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu Phone: (303) 906-2194

jcsteh commented 8 years ago

To clarify, I totally get the confusion here. It's just that the potential solutions all have downsides people don't expect which are in some cases even more likely to lead to confusion. Anyway, we'll see what we can come up with.

Adriani90 commented 5 years ago

@jcsteh, @michaelDCurran, @feerrenrut, @leonardder, @derekriemer have there been any further discussions on this issue?

josephsl commented 5 years ago

Hi,

Note that any new discussion MUST include a nod to #577. Thanks.

Adriani90 commented 1 month ago

An alternative proposal I have is

A complex additional dialog with all the settings and specifying which should be included in which profile, is gonna confuse users. On another hand, regarding profiles being corrupted unintentionally, I think people can avoid this by

  1. Uncheck save settings on NvDA exit check box
  2. Save settings only manually by pressing nvda+ctrl+c when you are sure that the setting should stay permanent. Still as of now this does not work on a profile by profile basis.