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.

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.

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.

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:

• Check whether a profile setting is equal to the global setting
• If so, ask the user whether they want this setting set explicitly for the profile, or whether they want to restore the setting to its globally set value.
• Alternatively, a setting could be added to one of the settings dialogs in other to choose the desired behaviour.

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.

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.

@jcsteh mind if I take this one?

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.

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!

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
#4892 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGivX-lBQ0Rutd_k4dBOyljxLvS-5hfks5q1HGngaJpZM4JESVm.

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

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

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
#4892 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGivUQC7BvoNkSP34SIJnDauDsnt5Bgks5q1J_qgaJpZM4JESVm.

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

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

==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
#4892 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGivUQC7BvoNkSP34SIJnDauDsnt5Bgks5q1J_qgaJpZM4JESVm.

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

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, @michaelDCurran, @feerrenrut, @LeonarddeR, @derekriemer have there been any further discussions on this issue?

Hi,

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