Allow excluding certain settings from configuration profiles #10156
Comments
|
Do other screenreaders on Windows allow this, or not.
I have a feeling that it might be very hard to do easily understandably
etc, on the property sheets used by nvda at present.
Brian
bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
-----
|
|
It wouldn't be done on the property sheets. It would be done, according to the
above suggestion, with a dedicated dialog off a button in the con fig profiles
dialog. That new dialog would abstract NVDA's settings into categories, and let
you switch them on and off for that profile.
(I.E. Synth settings, browse settings, etc.)
This is actually the first proposal of how to do this that seems remotely feasible to me.
|
|
Hi, so basically then, are we not kind of having things changing when you
are switched to a profile, but then not changed because you have excluded it
in another dialogue elsewhere?
Oh and by the way what is this new mail list you mention?
I came out of the normal mail list as moderation was getting counter
productive.
Brian
bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
|
|
Not really. The idea as I understand it (and prefer it), is that when you are
creating a new profile, let's say for use in Excel, you would have a "customize
profile effects" or some such button.
Let's say that you never want changes to pitch, volume, etc., to be saved in
that profile.
So you hit that customize button, and uncheck "speech" or whatever.
Then, you save the profile, and open Excel.
While using Excel (and thus the new profile), you adjust your speech rate. The
rate changes. Then you switch over to Firefox or something. The rate you chose
will stay the same, because the speech options are still global. If you save
changes to the Excel profile, speech changes will not be included. So next
week, you are feeling like faster speech again, and you increase the speech rate
again. Then, you open Excel. As it is now, the loading of the Excel profile
would slow your speech back to where it was during the previous session. But if
we implement this idea, since you have set it not to save the speech category,
it will continue at the rate set currently in the global profile.
As for your other question, regarding the mailing list that was in my email
signature: it is another NVDA users discussion group, but with a more newbie
friendly focus. It is more open to extended discussions on computer usage topics
that don't always exclusively relate to NVDA, because we believe that new
computer users especially, don't always understand where NVDA ends, and the
programs they are trying to use (or Windows itself) begins. It is not for new
users only, of course, but if we are inclusive in that way, it will benefit
everyone.
https://groups.io/g/NVDAHelp
…--
Luke Davis
Moderator: the new NVDA Help mailing list! (NVDAHelp+subscribe@groups.io)
Author: Debug Helper NVDA add-on (https://github.com/XLTechie/debugHelper)
|
|
@XLTechie Exactly. Excel is actually another nice example where this would be useful for me, because I have table coordinate reporting off globally because I don't care about it on the web, but it's much more important in excel. NVDA recently added a new checkable list control that developers can use, it's for example now used to set which keys are NVDA modifiers. It would work really well for my proposed suggestion here from a user experience point of view I think. |
|
This sounds really interesting. I use different profiles for different languages, but the only thing I want to have different in those profiles is the language of the synthesizer not anything else. There is how ever one critical question which has to be resolved before this feature can be implemented. I personally think that they should be off, I.E. no settings should be reflected in the profile specifically if one don't specify that. How ever, this has one downside. I think a solution might be to add some kind of dialog when changing some settings if those settings should be reflected in the current profile or not. It could be an extra button aside from the "OK" and "Cancel" buttons called "Reflect in current profile". Also, if the user just press enter within the settings to save them instead of pressing on the OK button, a dialog may appear asking if the changed settings should be reflected in the current profile or applied globally. These things should of course only be shown if a custom profile is selected and not if "(normal configuration)" is selected. What do you think? Tage |
|
tage64 wrote:
What should be default? Should all categories be on or off when creating a new profile?
I personally think that they should be off, I.E. no settings should be reflected in the profile specifically if one don't specify that. How ever, this has
one downside.
They need to be on, so users will get the behavior they expect without messing
with the more advanced settings.
It will not be the same as it is now. So users who create a new profile and changes some settings will not see those settings reflected in the profile if
they don't specify that explicitly. It will make users confused.
Exactly. The only way this change will likely be accepted by users, let alone
into core, is if it does not dramatically alter existing functionality in ways
unexpected to the user.
I think a solution might be to add some kind of dialog when changing some settings if those settings should be reflected in the current profile or not. It
could be an extra button aside from the "OK" and "Cancel" buttons called "Reflect in current profile". Also, if the user just press enter within the
settings to save them instead of pressing on the OK button, a dialog may appear asking if the changed settings should be reflected in the current profile or
applied globally. These things should of course only be shown if a custom profile is selected and not if "(normal configuration)" is selected.
There are problems with that. The largest is that people can change settings
without using the configuration panels. The most obvious of these is the synth
settings ring, but there are dozens of toggles and settings that can be changed
from the keyboard and that alter things that are otherwise changed via the
settings panels.
To me, the default issue can be solved much more easily.
If you open the configuration profiles window, with the global profile selected,
you will still have the button for editing what settings are effective. However
in that mode, since it can't change what's saved with the global profile, it
will instead set the defaults that are applied to any new profiles created.
|
|
I really hope this gets some attention. This is a major problem for me, as I use a few profiles that only have a few settings changed. For instance, in my MUD client, I want speech interrupt for typed characters off and I want punctuation set to none. I definitely do not want speech rate, key echo, or soundcard selection to affect the MUD profile. NVDA actively resists my attempts to change this; I can for example set the profile ini file to read-only, but whenever I manually save config, it produces an error. As an alternative to this suggestion, we could have a checkbox in the profiles dialog to prevent changes to all configuration options that aren't already included in the profile unless the profile is manually activated. I Know that once I set up my profiles, I don't want anything or anyone touching the way they're set up. I asked about this when they were first implemented and was told it would be confusing, but to be honest, I don't see how it isn't confusing right now. I'm technically competent and I don't expect my soundcard change to only affect MushClient simply because I set up a thing that turns off typing echo and happen to be in the app when I change soundcards. |
|
I suggest an other solution. This is rather a solution to #11256, but since #11256 has been closed in favor of this issue, I am commenting here where the discussion takes place. We could imagine to be able to have a button to lock/unlock the profile in the profile window. So the steps to configure a profile for the Foo application would be:
This solution has the advantage to allow to change only the wanted parameter on the contrary to other solutions suggesting to allow or prevent changes at a parameter category level. |
|
I too have been thinking in this direction, after experiencing the "Activities"
option on iOS Voiceover.
Activities are basically configuration profiles. You can configure them in
settings (a little inconvenient), and then they apply to specific apps, or in
specific contexts of apps, if iOS understands the app well enough.
Any changes you make (such as speech rate) then are ignored in the app, but
effect the non-app context (outside the activity).
If we were to do something like that (your lock strategy), it raises a question.
Let us say that you create a profile for Audacity, that increases the speech
rate, then you lock the profile.
What happens then, if you go into Audacity, and change the speech rate?
I can think of three possibilities:
1. Your change is completely ignored, or it fails with an error that the
parameter is locked.
2. Your change effects the default profile (global context), but has no effect
in Audacity. You could keep increasing the speech rate, but you wouldn't hear it
being faster until you left Audacity's profile. That is how iOS handles the
situation.
3. The speech rate changes in Audacity, but is not saved to any profile. In
other words, it is as if you changed the speech rate for the Audacity profile,
but it can not be saved with the profile locked. The default profile ignores
this change. I personally like this approach.
|
|
Clarifying my question above: I am asking only about changes to the setting that
was locked. You have already said what happens to non-locked settings:
… All subsequent setting changes (in parameter window or due to keyboard shortcuts) would be done in the main default profile even if the app Foo is active.
|
Yes, that is how I was seeing the things.
Notes:
|
|
I agree with this "value lock" proposal.
I think it is a good way forward.
Even if it later becomes good to have an attribute lock (in other words,
certain attributes only can be changed and saved), it will be easier to
implement if this value lock idea is done first, and I bet this will cover many
use cases anyway.
|
|
Agreed with the lock button; this is essentially what I was getting at with the "prevent further changes" checkbox. I think that if a setting such a speech rate is changed in the profile, and that setting is again changed while the app is open, it should still only affect the app in question. More specifically, the behavior I'm hoping to prevent is the addition of new settings into the profile. If speech rate is already a part of my audacity profile and I change it, it seems acceptable to have that only affect audacity, and maybe even save to that profile. But I don't want speech volume, punctuation, or anything else to be a part of the audacity profile, even if I adjust it while using Audacity. I would hazard a guess that for 99% of people who use profiles, once they set up the initial settings, they won't want any future ones to leak their way into the profile either. |
|
That does sound like a very ellegant solution which would also not be as confusing to new users. I very much still think something should be done about the current behavior. |
|
I sure wish something would happen with this. It's been a lot of years and I'm still constantly screwing up my config profiles because I thoughtlessly adjust the output soundcard or audio ducking or some other innocuous setting and it gets saved to the profile forever until I manually edit the INI. I can't think of a way this could be less user friendly. |
|
I run into that all the time, particularly due to the use of the synth settings ring and screen curtain. If I Alt +Tab between my open applications right now I'm sure I will hear at least 2 or 3 different volume levels. I improved the situation for me by telling NVDA not to save the configuration when exit but I still have to clean my any files manually from time to time. |
seanbudd
added
the
blocked/needs-product-decision
|
in gneeral I agree with @CyrilleB79's lock profile approach, including the combo box for the profile letting you to choose when to save the settings. Problem:
My proposal is to add a general keystroke which manually turns on and off the profile and applies the global configuration instead when focusing the application (e.g. nvda+shift+p). NVDA would report e.g. for Firefox "Firefox profile disabled, global configuration enabled". Pressing again, NVDA would report "Firefox profile enabled, global configuration disabled". |
|
@seanbudd could you please close #14593 (comment) |
|
@Adriani90 I'm not sure how your proposed idea would solve this problem? Unless this is something that would be available in addition to the locking features discussed earlier. NVDA already has a facility to add hotkeys to toggle profiles, but it has to be enabled for each profile so I guess having a temporarily disable app specific profile command could be useful. But I don't see how it might solve a situation like described by others and myself earlier. |
|
@pitermach your explanation suggests you want to use temporarily some of the global settings on an application where you currently created a profile for. So that means you want global settings to be applied on the profile only for a certain period of time. Right? |
@Adriani90, sorry, I do not understand this part. |
|
@CyrilleB79 this was just a summary of what @pitermach described as expected. He wants to change a setting on the global profile and this should be reflected also when using the application with the specific profile. That's why I have proposed to have a way to temporarily disable the application profile and enable the global profile, then switch again to application profile when needed, all by pressing nvda+shift+p. |
|
@Adriani90 how does that help the problem you described?
If you turn off the profile (disable triggers, I think we can already do this to
achieve the effect you describe), of course the global profile applies as you
say.
But what does that serve? As soon as you turn the local (app) profile back on,
the global settings are reverted to whatever the app profile contains. So the
problem you describe is not solved.
I agree that the Voiceover approach is not ideal, and I understand the problem
as you have defined it and can at least potentially agree that it should be
solved in some way. But I don't understand how your proposal does that.
|
|
@XL wrote:
Not entirely, but at least temporarily when some global settings are more useful. For example
My proposal is maybe not the best solution. But in this case I can apply temporarily the global profile with nvda+shift+p on the website I need the table headers, and the role to be reported, and alternatively I can disable the global profile again and enable the Firefox profile with nvda+shift+p on the website I don't need the headers and the table role to be reported. Having a list of settings where I choose which one should be excluded from a profile is an overkill in this case, but this is only my opinion. |
|
@Adriani90 I understand better what you are thinking with that suggestion, thanks. I think @CyrilleB79's solution in #10156 (comment) is best. I may make an attempt to implement this, as I have been running into this annoying issue myself recently. |
|
If you want to change whether table headers are read, make a hotkey for it. If you have many settings you want to quickly swap between, make a separate profile that includes those settings, and then set a hotkey to activate it. This idea is kind of adjacent to the issue. Having a lock/unlock (or "prevent further changes") button would cover 95% of use cases. Then we could take stock of whether people want to be able to control automatic configuration saving on a per/profile basis. Personally, I would be fine with changes to existing settings within a profile being saved to that profile. I imagine most profiles will have fewer than 10 settings in them, and the existence of the lock/unlock button would mean that any settings added to the profile are very intentional, so most users should know that adjusting those settings will cause changes to be made to the profile where they reside. If people don't like the automatic saving and someone creates an issue for it, then maybe a further addition to NVDA could allow profiles to be permanently locked so that no further settings changes would be saved to the profile at all. But this is confusing. That means if I adjust speech rate in Audacity when there's a profile active, that speech rate won't be saved at all, but if I adjust speech rate on my desktop, that change will be saved to the configuration file on exit. I don't find this approach intuitive at all. Most importantly, settings are already saved automatically, including new ones that leak into the profile. I want to focus on pushing for a single change at a time. I think we can all agree that we badly need a lock/unlock button. (If anyone disagrees with that, feel free to chime in.) If we can get that done, that's out of the way, and then any necessary discussions can happen about future enhancements/changes to the way that works. |
|
@Simon818
I think the question isn't whether to have a lock/unlock button. The question is
whether it should be a value lock or a parameter lock.
I believe @CyrilleB79's lock proposal was for a value lock, where once the lock
is engaged, nothing new is added to the profile for any reason.
I believe you are saying you would prefer a parameter lock, where once the lock
is engaged, only parameters which were previously changed, are ever saved in
that profile. Values for those parameters could still be changed and saved in
the profile, but no new parameters could be added while locked.
I can see arguments for either or both. Value is easiest to make happen, of
course, but I am right now leaning toward your argument as being more user
expected.
|
|
@XLTechie I hear what you're saying. I don't know the specifics of coding a system that allows value changes to existing parameters but prevents further parameters from leaking into the profiles. however, it seems like these are separate functions of the profile system and either or both should be possible. I also feel like the value lock would be extremely user-hostile and would just solve one problem while introducing another. There are too many considerations and unexpected behaviours for me to be in favour of this approach. For instance, if your profile for browsers automatically disables reading of table coordinates, you want to be able to re-enable those in case you need them on a particular website. If there's a value lock on the profile, you can still re-enable coordinates, but then, when does that setting revert back to default? If I go back to the desktop and then back to the browser, has NVDA temporarily saved my setting change to memory, in which case it will apply it to the browser again? Or will it be more like JAWS, where a setting change will only apply until you switch out of the window, and then it will permanently revert? If it's the former, this is confusing because people are likely to leave NVDA running for long stretches of time, so a change to table cell coordinates will probably stay in effect for quite some time as well. But then, it will immediately revert after the first NVDA reload, which could happen at any time for any reason. This could cause confusion when users wonder why their table coordinates are back to not reading. If setting changes only apply until you switch in and out of the profile, switching out of the browser window to read an incoming message--or, for that matter, getting a pop-up alert from another application would cause the table coordinates setting to revert to being disabled, as per the saved profile. And in both cases, users who haven't read the documentation carefully would expect a ctrl+nvda+c to save any changes they make to the profile. It's strange to have throwaway settings in certain contexts and permanent / saveable settings globally. So until we can work out a more sensible approach, I can't really vote in favour of the value lock. I think the lock button should simply prevent further settings from accidentally leaking into the profile. In addition to this being more user-friendly, the issue title is "allow excluding certain settings from configuration profiles", not "allow users to prevent further changes to configuration profiles", and the parameter lock would fit @pitermach's use case even if it isn't exactly the proposed solution. It also saves developers from needing to plan, design, and test an entirely new UI for adding only certain settings to the configuration profile. The lock button would decide which settings to include in the profile, rather than deciding exactly what the value of those settings should be. Curious to hear thoughts of others who have weighed in here, in case I've missed something. |
|
@XLTechie wrote:
@XLTechie I think combining profile setitings with inherited settings from global profile can get very complex, especially when people have a lot of profiles. I guess we would need a lot of temporary ini files where the combined settings are stored for the time the profiles are locked. Not sure this is efficient. Is the leaking feature really needed? Or could people live with the nvda+shift+p solution which can switch between aplication profile and global profile on demand? |
|
@Simon818 wrote:
As far as I understand @CyrilleB79's approach, the lock button would not write further settings to the profile.ini file for the focused application, but settings from global profile will be inherited to the locked profiles. So for example if you lock 5 profiles, settings you change on the global profile will inherit also to all 5 locked profiles. When you unlock them the profiles will resume to the usual profile.ini file. In fact, this is kind of a more manual approach of my nvda+shift+p approach, with the advantage that you can apply it to more than one profile at the same time. |
|
@Adriani90 asked:
Do you mean the "locking" feature? Because leaking is the symptom for which @CyrilleB79 proposed locking as the solution.
Some might, I certainly can't speak for all use cases. However it doesn't really solve the problem that people complain about. Consider:
Now, let us say that your suggestion is implemented.
Now the speech rate is saved in two places, when really it is only desired in one. |
|
@Adriani90 wrote:
I think this is true. So it is with any advanced feature. If you choose to use it, you take the risk that it might confuse you, and you must learn its intricacies and comprehend its documentation. Profiles are already an advanced feature, it is just one that has become ubiquitous in screen readers because of its obvious utility.
Why should that be necessary when it isn't necessary now? Currently, settings that have not been changed in the active profile, are read from the global profile. That situation would not change. No config file, temporary or otherwise, is necessary to tell NVDA which settings are not part of the profile. Profiles are not subtractive, they are additive. Or, said another way, the profile's settings "cover over" the global profile's settings. Locking a profile requires only a single flag (or two, at most), saying "If a non-overridden parameter is changed, pass it through to the global profile". While I haven't tried it, that flag should be able to be stored in the profile's own |
|
My main concern was to avoid new parameters leaking in a specific profile. E.g. I define a word profile where punctuation level is set to all. I want to be able to lock Word profile so that only punctuation level parameter belongs to Word profile. Once Word profile is locked, modifying speech rate in Word should should modify the speech rate in the global profile. After reading @Simon818's comments, it's clear that being able to modify the profile's parameter(s), e.g. punctuation level in Word profile, is the simplest choice from a UX point of view; it avoids to define what happens if I modify punctuation level in Word when its profile is locked? And what happens when turning back to global profile? I also fully agree with @Simon818 regarding the fact that one issue should be handled at a time. This issue is becoming always more complex. I'd vote for implementing the lock profile button/checkbox in a first step. Then we can play with it and see if something else should be added or not. @Adriani90, not sure to understand your explanations regarding inheritance between profiles. Please provide an example to make things clearer if you expect an answer from me. Thanks. |
|
@XLTechie wrote:
good point, Thanks this clarifies my question. |
|
Actually reading through this I really support the idea of the lock profile feature. I will create a new issue summarizing the conclusion and bring the discussion on point. It seems the community agrees on @Simon818's approach as per comments above. |
|
Closing in favour of #17409. |
Is your feature request related to a problem? Please describe.
I have created a configuration profile for an application to slightly tweak NVDA's verbosity - turning off reading of table headers. I don't want this profile doing anything else. Sometimes when I'm in this application I'll adjust other settings like speech rate and synthesizer to a different language, and NVDA writes these changes into the profile. If I later make a similar change to my main profile and return to this application I find NVDA is still using those settings saved in the profile. Currently, there's no easy way to tell NVDA to use the global voice settings so I either have to make sure they match, or open the profile's ini file in notepad and manually erase the section so NVDA uses my global settings.
Describe the solution you'd like
VoiceOver on Mac OS solves this kind of problem by letting you pick from a list what kinds of settings should be included in an Activity (VoiceOver's version of a config profile), including categories for speech, braille, verbosity and so on. If a category is checked and I make a change in that group with a hotkey while I'm using that program, it gets saved in the activity. If the category is unchecked, then the change is made to global settings instead.
I think that NVDA should offer a similar option in the dialog box to edit a profile. Probably the simplest way of presenting the list is just to look at what sections are included in the main nvda.ini file, perhaps excluding some of them like the sections for synthesizer-specific parameters
The text was updated successfully, but these errors were encountered: