Sleep mode part of profile configuration request

[nvaccessAuto]

Reported by isaacporat on 2013-12-15 09:04
I use and develop self voicing applications (SpeakOn). Now that NVDA supports profile configuration it would be wonderful if sleep mode can be part of the profile configuration in particular with triggered profile related to applications.

Thank you
Isaac Porat
Blocking #4858

[nvaccessAuto]

Comment 1 by briang1 on 2013-12-15 10:18
Surely this is best done in a bespoke add on so it triggers when the ap is loaded like most app modules do.
The syntax is probably going to suffer ehen I paste this example sorry!
import appModuleHandler
class AppModule(appModuleHandler.AppModule):
sleepMode= True

You can of course manually turn on sleep, but doing it this way its automatic. There are already some built in to nvda. Cicero comes to mind, and I've seen an add on for Guide.

[nvaccessAuto]

Comment 3 by bdorer (in reply to comment 2) on 2013-12-15 12:27
You shouldn't write your comment into the changes entry field! It's for the what's new item in the changes file.

Replying to isaacporat:
You of course correct and I am aware of this. Not everyone is a programmer to create their modules and there should not be a need to bother the developers with each new self voicing application. With the way I suggest it, when a profile for a self voicing application if a user turn sleep mode off it just sticks from that point that is every time the application is started NVDA goes to sleep mode off. All major commercial screen readers support this feature. With some like Jaws it is easy to configure with some others it is more complicated.

Anyway, this is not a major issue and as you say can be turned off manually but as I and some others use this feature a lot it would be very useful.

[nvaccessAuto]

Comment 4 by briang1 on 2013-12-15 19:33
Maybe what is an entry such as. Engage sleep mode on this application, every time it is focussed.
In fact this is exactly what the code I put did for me. I just called the file I was adding xxx.pi where xxx was the name the application executable showed when doing an nvdaF1.

One would need to save the setting, and i am sure it is not that easy to write an add on to do this, though its probably beyond me.

[Adriani90]

Actually sleep mode can already be turned on only for current application with NVDA+Shift+z in laptop layout or nvda+shift+s in desktop keyboard layout. See input gestures dialog.
@ehollig can you confirm?

[ehollig]

The keystrokes you reference @Adriani90 is correct. The request here is to have sleep mode be saved with a configuration profile.
Steps to reproduce:

1. Open a program
2. Press NVDA+N, C, alt+N
3. Give the profile a name
4. Select "use this profile for current application"
5. Change something noticeable, like the speech rate
6. Turn on sleep mode by pressing one of the above commands @Adriani90 pointed out in Sleep mode part of profile configuration request #3721 (comment)
7. Switch to another program and notice your personal settings is back
8. Restart NVDA
9. Go to the original program in step 1, and notice the noticeable thing changed for the profile, like the speech rate, was saved, but not the sleep mode setting

[Qchristensen]

Just bumping this since it's still being requested.

[XLTechie]

Definitely agree that this needs to be implemented, and soon. The topic comes up often enough on the user list (people wanting to save the sleep state for an application, and by far the easiest way to do that would be configuration profiles).

[lukaszgo1]

While I agree that it is needed before anyone would code this the UX needs to be discussed. What about the following:

1. In the configuration profiles dialog add additional profle by default called SleepMode.
2. When you want to have permanent sleep mode for a particular program you would simply create a trigger for it and assign SleepMode profile.

The current command for enabling sleep mode would remain available and would like it does now enable sleep mode until NVDA restart.

[Qchristensen]

Instead of creating a new "sleep mode" profile, why not simply save the sleep mode state as part of the config profile? That way all you would need to do is start that program, create a configuration profile for it, then turn on sleep mode.

I wonder if it would be worth having some kind of earcon or verbal notification the first time NVDA goes into sleep mode any time it's run. That way if you start NVDA while you have such a program running, (or the first time you start or change to that program), you will hear NVDA start then advise you that it is in sleep mode. Just to avoid confusion about why NVDA stops speaking (in case you forget you created the profile).

[XLTechie]

Instead of creating a new "sleep mode" profile, why not simply save the sleep mode state as part of the config profile? That way all you would need to do is start that program, create a configuration profile for it, then turn on sleep mode. Having tried this, I wonder how exactly one would save such a profile? Unless the save config command was exempted from sleep mode, which could be done, although that might defeat the purpose. To imagine: you create a profile that triggers on an app, load that profile, enter sleep mode, and then what? NVDA is now sleeping, and ignoring your commands.

[XLTechie]

I can see this "sleep profile" solution as workable, but only if it works also when the user has multiple apps that require sleep. I can't check an NVDA system right now, but will triggers let you apply more than one trigger to a single profile? If so, that might be the best answer going at the moment.

[lukaszgo1]

I can see this "sleep profile" solution as workable, but only if it works also when the user has multiple apps that require sleep. I can't check an NVDA system right now, but will triggers let you apply more than one trigger to a single profile?

Yes, it is possible to create a profile, and trigger it in more than one program.

[Qchristensen]

why not simply save the sleep mode state as part of the config profile? That way all you would need to do is start that program, create a configuration profile for it, then turn on sleep mode. Having tried this, I wonder how exactly one would save such a profile?

Good point. In my defence, I never claimed it was a well thought through idea!

[Qchristensen]

Perhaps having "NVDA control+c" still active when in sleep mode would work - that way a profile using sleep mode could be saved - and if you have "save configuration on exit" set, you shouldn't need to do anything, it would simply be saved.

It's unlikely that either INSERT+CONTROL+C or CAPS LOCK+CONTROL+C would be used by another program.

[lukaszgo1]

To summarize after reading this ticket and others marked as a duplicate of this one it seems there are three possible solutions:

Separate profile for a sleep mode.

• Always present in the configuration profiles dialog perhaps at the last position
• Can be only activated when triggered and trigger is associated with any application i.e.e not for say all.

Pros: Associating given program for the GUI is quite explicit action which probably cannot be done by mistake. It can also be very easily reverted as triggers can be changed from anywhere.

Cons: It would require support for stacking of profiles that is being able to associate more that one profile with one program. All settings other than sleep mode would need to be loaded from the second profile assuming that there is one associated. It should also be decided what happens when switching sleep mode off using a keyboard command.

Additional checkbox for sleep mode as part of settings

This would require additional checkbox either in one of the existing settings panels (which one?) or additional settings panel named Profile specific settings or similar. This checkbox or entire panel if it is going to be separated should be shown only when profile other than the default is active.
Pros:

• Again this is not easy to activate by mistake so good for beginners.
• The problem of different profile for settings and sleep mode disappears as they are stored inside one profile.

Cons:

• We do not have settings which are shown only when config profile is active so this can be possibly confusing for users.
• As in the previous point we need to decide what to do when the gesture for sleep mode is used.

Save sleep mode when the gesture is used inside an active profile

When pressing the keyboard shortcut for enabling sleep mode and configuration different than default is active the fact that sleep mode has been enabled/disabled is saved inside active profile. This would require NVDA+Ctrl+C to be active even in sleep mode to facilitate people who don't have saving of config on exit enabled.
Pros:

• The most intuitive option - almost every other setting changed via keyboard command is saved in the active config.

Cons:

• The easiest option to be activated by mistake
• The fact that the change is not going to be saved if no profile is active maybe confusing.
  Perhaps to mitigate this we should create a profile associated with the active program by default and save there?

@feerrenrut While I don't plan to work on this until #11006 is open would you be able to share your thoughts about the implementations outlined above and let me know which one would you prefer?

[XLTechie]

Another possible option would be to place an option in the profile configuration dialog. A checkbox to the effect of: Start this profile in sleepmode. The user would probably only be able to select it when creating the profile, or when otherwise not actually running the profile, but it would serve the purpose with minimum impact.

[lukaszgo1]

@feerrenrut Have you seen my above comment listing possible implementations? Would you be able to tell which one would you prefer and/or propose different UX. This is being asked for on various mailing lists pretty often so there is clear demand for this feature. Also cc @michaelDCurran or @seanbudd if you'd like to provide your thoughts about implementation.

[seanbudd]

As someone not incredibly familiar with this issue, I think the first option "Separate profile for a sleep mode." makes the most sense.

It should also be decided what happens when switching sleep mode off using a keyboard command.

To answer the above, I would propose changing the input gesture to activate/deactivate the entire sleep mode profile (if other settings are included), rather than "sleep mode" specifically.

[feerrenrut]

Thanks for the summary @lukaszgo1, it makes it much easier to get up to speed on the issue.

My preference would be either on the Profile config or on the Trigger.

I think there are too many edge cases in the "Save sleep mode when the gesture is used inside an active profile" case. Mixing a temporary setting with a saved one. This is an ongoing difficulty with screen curtain.

The "Separate profile for a sleep mode." is quite a technical solution, I think it is more difficult for users to understand than it needs to be.

[lukaszgo1]

Thanks for your comments @feerrenrut

It looks like the following does what we need:

• Command for activating sleep mode does not affect config at all i.e. just disables / enables until NVDA is restarted.
• When starting settings dialog with an active profile there is additional settings panel (lets call it "Application specific settings" tentatively) which contains a checkbox called "Enable sleep mode for this profile".

Would something like this be an UX you can accept a PR for?

[feerrenrut]

When starting settings dialog with an active profile there is additional settings panel (lets call it "Application specific settings" tentatively) which contains a checkbox called "Enable sleep mode for this profile".

This is a little confusing. I think the profiles concept isn't very clear in NVDA settings at the moment. But currently the majority of settings are tied to the active profile already.

Rather than think of this as a setting, it could be thought of as an action. A profile trigger could also be thought of as an action eg "swap to this profile". I think an option such as "enter sleep mode on activation" belongs on the trigger dialog.

I now think it doesn't belong in the profile dialog (but does belong in the trigger):

• profiles can be be enabled manually, it doesn't make much sense to enable sleep mode when the profile is enabled manually.

[lukaszgo1]

My only problem with adding additional checkbox on the trigger dialog which, when checked, would activate sleep mode for a given trigger is the fact that it is horribly not discoverable. I certainly would not even imagine to look for such option there and I believe most users would not either. All other AT's simply adds additional checkbox to the application specific settings though it is probably because NVDA is an only screen reader where triggers are separated from the configuration.

[feerrenrut]

I'm not so sure, wouldn't they have had to visit that dialog when creating the profile / trigger in the first place. Granted, for existing profiles this is a concern.

[lukaszgo1]

@feerrenrut Imagine that as a user you want to enable sleep mode for an application and hunting for an appropriate option. Would you look in the triggers dialog for it? I certainly would not. In addition if we would ever add a search option to the settings dialog the "enable sleep mode for the trigger" would not be included in the search results.

[Qchristensen]

My concern with a checkbox for sleep mode on the profile page is that it is inconsistent - to set any other option for a profile, you trigger the profile, then change the option.

Perhaps a solution could be to save the sleep mode state as with any other option, but also add a cue so that when you trigger a profile set to sleep mode, NVDA reports something like "entering sleep mode". An argument could be made for simply doing that whenever sleep mode is activated (eg when you press NVDA+shift+s / NVDA+shift+z). Or an earcon like screen curtain uses.

[XLTechie]

@marrie, I have created a separate issue for a sleep mode sound requirement. Comment on it if you like: #13532.

[Gene703122]

I am not a programmer and this may be an instance of a simple solution that has problems, but why not just do this in the most simple and direct way? No profile would be needed, and it should be in the core. When you evoke the sleep mode command, a dialog comes up. Enter sleep mode automatically when in this application with a yes or no button.

If you want to turn automatic sleep mode off for an application, have a command that opens a list of items that go into automatic sleep mode. Each item would be a check box. Uncheck the check box, activate the ok button and the behavior is removed for that application. It could be a command and also found in NVDA settings, as so many settings are.

I would think there are many applications users have no need to create a profile for and I don't think it should be necessary to create one just for this purpose.

[marrie]

That would actually be more trouble than it’s worth. In theory you would have to have a loop scanning the system for apps every time that command is invoked. It’s better to create a profile for more user flexibility, even if it is a temp profile.

[XLTechie]

@Gene703122, I think that you may have interpreted some of my listed steps, as user steps. Most of what I wrote was a technical implementation proposal. From a user prospective, what I suggested would work mostly as you have requested, because of the automatic generation of sleep mode only profiles as I described.

That said, I had an alternative proposal which was completely divorced from profiles, which I will present below.

Edit (2024): I forgot about coming up with this, and proposed something similar but different (I think better), in #16305.

1. Create a settings panel for sleep mode. It would include:
   • a "remember sleep mode" checkbox;
   • a selector for the sleep mode alert indicator;
   • a list of apps that NVDA knows about, with a "remember sleep mode" checkbox for each (modeled on @josephsl's Add-on Updater settings panel where you can choose which add-ons get updated and which don't).
2. When an app is opened, and sleep mode is entered for the first time:
   • If "Remember sleep mode" is checked, the app is added to the list mentioned above, and automatically checked to "on".
   • If "Remember sleep mode" is not checked, the app is added to the list, but its individual "remember" box is unchecked by default.

This doesn't include the "Always start in sleep mode" feature I added into my initial proposal above. We would either need a second list for that (like @josephsl has for whether to use development versions of add-ons), or would need to drop that feature.

@feerrenrut I am happy to implement either proposal, as NV Access prefers for this feature.

[josephsl]

Ho, I think a simpler approach might be a checkbox or two in Advanced settings panel that will be shown if and only if an app-specific profile is active. This simulates what JAWS does. Thanks.

[XLTechie]

Ho, I think a simpler approach might be a checkbox or two in Advanced settings panel that will be shown if and only if an app-specific profile is active. This simulates what JAWS does. Thanks.

@josephsl can you elaborate on this somewhat? I am unclear how this would work.

Also, I am re-thinking both of my proposals above. When I loaded this issue earlier today, GitHub was only showing me about six of the comments; none of those from @feerrenrut or @seanbudd or @lukaszgo1. I have no idea why that happened, but upon opening it again to post my last comment, it brought up the full history.
I'm still willing to do any of what I talked about, but I see that various other ideas have been gone over before, such as the multiple trigger sleep profile, although that has problems.

[josephsl]

Hi, in theory Advanced settings panel is supposed to be profile neutral – that is, it is supposed to apply everywhere, but it is not. Therefore we can take advantage of this fact and say that sleep setting (flag) will be tied to profile triggers – that is, whenever NVDA loads a new app module, it will check for sleep mode flag in addition to determining if an app-specific profile is defined for this particular app. In other words, I’m suggesting that we look at the actual internals of configuration profiles, as a preliminary UI design will come to our minds if we think carefully about the config profile trigger structure and internals (after all, profile triggers is a key component of what makes profiles profiles). Thanks.

[XLTechie]

@josephsl if I understand you correctly, the user workflow would be:

1. Open the desired app.
2. Create a profile set to trigger when that app loads.
3. Open NVDA advanced settings.
4. Check the scary box to be able to modify those settings.
5. Check a "start this app in sleep mode in this profile" box.
6. Apply the settings [and save].
7. Start sleep mode manually in the app for this first time.

After which, any time that profile triggers, it starts in sleep mode.

To stop starting in sleep mode, the user either deletes the profile, or turns sleep mode off, goes back to advanced, and unchecks the box?

Personally, that seems overly off-putting as compared to, for example, my last proposal above. On the other hand, from a development point of view, it would be rather easy to do.

[feerrenrut]

I don't think I can recommend an approach at this stage. This issue contains a lot of focus on solutions, without much focus on the underlying problems / user stories, the remaining questions on this issue are essentially due to the UX problem. Rather than suggesting solutions and hoping others here infer the same benefits to the approach, let's try to be explicit about the reasoning.

Background on sleep mode

The docs for the sleep mode command:

Toggle application sleep mode on and off (NVDA+shift+s | NVDA+shift+z )
Sleep mode disables all NVDA commands and speech/braille output for the current application. This is most useful in applications that provide their own speech or screen reading features. Press this command again to disable sleep mode - note that NVDA will only retain the Sleep Mode setting until it is restarted.

Primary user story

The following user story is the one I imagine:

As an NVDA user, when encountering a noisy application, I can easily create a profile that automatically triggers and stops NVDA from reporting that application.

Notes/questions on "noisy application":

• Self-voicing applications.
• Are there other use cases, such as noisy due to live regions, or due to intermittent foreground events (such as cmd windows opening briefly during an installer)
• Why else would you want to enable sleep mode?

Some UX properties that are important (in my opinion):

• Creating the the "sleep mode profile" is low friction.
• Determining the current state of sleep mode is intuitive.

Design constraints

There are some unusual restrictions compared to other NVDA settings.

1. Sleep mode is tied to an application or potentially some accessibility subtree.
2. Profiles aren't tied to an application. A profile trigger can be tied to an application (or say-all).
3. A sleep mode setting really doesn't make sense on the base profile (because it should be tied to an application).
4. There isn't an obvious category in the NVDA settings dialog for sleep mode.
5. It doesn't make sense to have this sleep mode enabled when a user manually triggers a profile. It would be very fiddly for a user, likely would lead to mistakes I.E. the application would need to have focus in order to apply sleep mode to it, but NVDA would have focus during profile selection.

Some ideas

1. Add a general "trigger commands" concept to profile triggers. Let users configure scripts to be run on activation. This could include enabling sleep mode for the current application, but also other things like reporting a message. This would need to take into account the type of trigger used, application vs say-all.
2. Add a category to NVDA settings, only enabled when a profile is enabled. This would house a sleep mode checkbox. The label would need to explain it is only used when there is a an application profile trigger. EG Sleep mode when profile triggered by application
3. Add the category as per 2. also add an option to the trigger creation to streamline the setup. These to options would need to be synchronized.

[marrie]

I actually do apply sleep mode to a game profile mainly because even though it’s voiced by nvda, at least nvda’s voice, nvda’s keys can interrupt the game, so I turn on sleep mode in its profile, but often forget I’ve enabled sleep mode somehow in default so I get speech sort of but not really. I can run the programs like outlook but get no output when I launch the run dialogue or alt tab. So there really does need to be an alert when you alt tab into a profile where you did enable sleep mode. Something like “sleep mode enabled.”

[Qchristensen]

Re the original use cases and questions, re noisy applications. I recommend we focus on the self-voicing application scenario. This is the only one I have heard this feature requested for, and the one I anticipate it would be most used for.

If there are constraints around sleep mode being tied to an application, then if we could only allow it to be set in a profile which is triggered by the current application, that would again fit in with the primary use case anyway.

[feerrenrut]

If there are constraints around sleep mode being tied to an application

This is my understanding. I'm not aware of a more general sleep mode concept. If anyone has a contrary understanding it would be good to know about it so we are basing decisions on the same understandings of the constraints.

then if we could only allow it to be set in a profile which is triggered by the current application, that would again fit in with the primary use case anyway.

I've tried to highlight that the UI for this isn't obvious. We don't have options in settings that disappear based on the current profile. Additionally, any profile can be manually triggered. Current application no longer makes sense when the Settings dialog is open, because it is now NVDA.

[josephsl]

Hi, I understand that it might be off-putting to users. But we should also emphasize the fact that advanced settings are meant to be changed by people who know what they are doing (especially under guidance from NV Access and other developers). Which begs a follow-up question: should we separate some advanced settings into a panel dedicated to devleopers? I think that might be something to have as a separate discussion (not this issue). Thanks.

[marrie]

Agreed on your point. Can someone start an issue on this extra panel? 👍

[Adriani90]

To be honnest, after reading through all the conversation at least in my opinion many UX proposals are quite an overkill for what the solution should look like.

Problems:

1. NVDA cannot remember which application had sleep mode enabled after NVDA restart or after application restart
2. Sleep mode interferes with other profiles when changing settings, that means the user cannot change NVDA settings while sleep mode is enabled

New proposal:

1. Save sleep mode state for the application in a sleepMode.ini file based on the name of the executable of the application as soon as the user changes the sleep mode state for the first time (similar to what our configuration file does when changing the default value of a setting for the first time, the same could be done for screen curtain in a screenCurtain.ini file
2. Make NVDA capable to have its own profile so that NVDA menus, dialogs etc. can be accessed even though sleep mode is enabled in a specific application.

Advantages:

• No dialogs with checkboxes or combo boxes needed
• No manual profile triggers needed
• Probably one of the easiest way to technically implement because we already have everything in place for this to work
• Sleep mode remains separated from profiles and can still be tied to applications

[Adriani90]

The NVDA specific profile is covered in #15165.

[josephsl]

Hi,

A few housekeeping task suggestions:

1. Short of starting a new issue with the issue template filled in (or a new discussion), I think we need to reorganize this issue entirely. We spent the last five years debating solutions proposed by several people (I myself wrote earlier that we need to analyze config profile internals if we are going to work on profile based solutions).
2. Expect proposals that approach the heart of this issue (app specific sleep mode feature) from multiple angles, including config profiles, configuration databases, app usage and sleep mode history, among others.
3. When we propose something, let us NOT FORGET to discuss disadvantages/drawbacks/limitations as doing so improves comparisons and assists in informed decision-making. I understand that discussing drawbacks/disadvantages/limitations could be a bit hard, but doing so shows you are committed to your proposal and thought things through (if you are planning to be a software engineer (or perhaps become a more thoughtful community participant), evaluating different possibilities and their advantages/drawbacks is a skill you should have, especially if you are responsible for coding alternative access to information for thousands of people).

Thanks.

[marrie]

I can see one disadvantage. Let’s say the end user restarts nvda and they happen to be in a config with sleep on. They might forget and nvda would not default to the non-sleep state when restarted. I do not have a solution to propose to fix this yet, it is something to consider. Was this already brought up somewhere? Keep in mind I do not code. This would be a huge issue in my book and something to think about before implementing.

[Adriani90]

@josephsl

I think this #3721 (comment)
and this #3721 (comment)
are already covering the current state we have so far, and I tried to come up with a proposal via my two comments above to avoid the constraints @feerrenrut pointed above.

[lukaszgo1]

2. Sleep mode interferes with other profiles when changing settings, that means the user cannot change NVDA settings while sleep mode is enabled

I do not understand this part at all.

1. Save sleep mode state for the application in a sleepMode.ini file based on the name of the executable of the application as soon as the user changes the sleep mode state for the first time (similar to what our configuration file does when changing the default value of a setting for the first time, the same could be done for screen curtain in a screenCurtain.ini file

There are several issues with this making it IMHO not worth debating further:

• NVDA has a support for settings included only in the base config - why introduce additional .ini file?
• This changes behavior of existing command i.e. for as long as it existed it was temporary and now you suggest to make its state saved in the config - why you think changing the existing behavior is justified? Also it will mean that user selected and, until now temporary, state, will overwrite what is enforced by app modules.

2. Make NVDA capable to have its own profile so that NVDA menus, dialogs etc. can be accessed even though sleep mode is enabled in a specific application.

This is not a concern at all since when sleep mode is enabled for a current application you cannot (and should not as one of the reasons for enabling sleep mode is being able to pass through all keyboard shortcuts to the application) access NVDA's GUI.

• No dialogs with checkboxes or combo boxes needed

This has to have a GUI because we don't have any permanent option which can be enabled via a keyboard command only and making that change changes the established behavior of NVDA+Shift+S anyway. That is not something which should be done.

• Probably one of the easiest way to technically implement because we already have everything in place for this to work

This is not easier than what has been proposed in #16305 - trying to establish difficulty level of a coding task as a non programmer seems just trying to add unverifiable arguments in favor of your proposal.

[Adriani90]

2. Sleep mode interferes with other profiles when changing settings, that means the user cannot change NVDA settings while sleep mode is enabled

I do not understand this part at all.

I think this was not fully related, I was thinking of @marrie's problem of NVDA keys interupting the game. So if that's why sleep mode was enabled for the game, the user could go afterwards into the NVDA menu and create a profile for the game, disable the nvda input gestures that cause the game to be interupted, and if that works, then sleep mode can be disabled again. With the current situation you can do taht only when leaving the game window and focusing another application or the desktop but you still don't have a profile for the game application.

1. Save sleep mode state for the application in a sleepMode.ini file based on the name of the executable of the application as soon as the user changes the sleep mode state for the first time (similar to what our configuration file does when changing the default value of a setting for the first time, the same could be done for screen curtain in a screenCurtain.ini file

There are several issues with this making it IMHO not worth debating further:
• NVDA has a support for settings included only in the base config - why introduce additional .ini file?

Well, if the base only configuration support helps in remembering the sleep mode states for the applications, even better. We could go that way which is more efficient ofcourse.

This changes behavior of existing command i.e. for as long as it existed it was temporary and now you suggest to make its state saved in the config - why you think changing the existing behavior is justified? Also it will mean that user selected and, until now temporary, state, will overwrite what is enforced by app modules.

IN case of app modules I don't know any example that enforces sleep mode by itself.
Introducing a save sleep mode state for an application is what this is all about. Not sure I understand your argument here.

2. Make NVDA capable to have its own profile so that NVDA menus, dialogs etc. can be accessed even though sleep mode is enabled in a specific application.
   This is not a concern at all since when sleep mode is enabled for a current application you cannot (and should not as one of the reasons for enabling sleep mode is being able to pass through all keyboard shortcuts to the application) access NVDA's GUI.

This is not a concern at all since when sleep mode is enabled for a current application you cannot (and should not as one of the reasons for enabling sleep mode is being able to pass through all keyboard shortcuts to the application) access NVDA's GUI.

Not if you are in a game, want to create a profile for that game and try to solve some NVDA/game key conflicts before disabling sleep mode again.

• No dialogs with checkboxes or combo boxes needed

This has to have a GUI because we don't have any permanent option which can be enabled via a keyboard command only and making that change changes the established behavior of NVDA+Shift+S anyway. That is not something which should be done.

Actually just some examples, the native selection command or the input help command cannot be enabled via the GUI either. So if this is your argument, then there should be a separate request discussing all permanent settings should be handled both via GUI and key commands.
In my view this is out of scope for this particular request and could be done in a subsequent step.

[Adriani90]

iN the end it might be the best either to let now the decision at NV Access whether they want to reopen #16305 while closing this one or let both open or what ever.

I think there is enough material in place now to shape a pull request considering all the input here. Then the discussion can go deper into the technical things on a concrete pull request.

[lukaszgo1]

I think this was not fully related, I was thinking of @marrie's problem of NVDA keys interupting the game. So if that's why sleep mode was enabled for the game, the user could go afterwards into the NVDA menu and create a profile for the game, disable the nvda input gestures that cause the game to be interupted, and if that works, then sleep mode can be disabled again. With the current situation you can do taht only when leaving the game window and focusing another application or the desktop but you still don't have a profile for the game application.

That is indeed not related at all, since to make this work input gestures would have to be profile aware, which they currently aren't. This should have its own issue if further discussion is needed.

IN case of app modules I don't know any example that enforces sleep mode by itself.

There are several in NVDA's core i.e. dosbox, doctts, cicero and some more which I haven't listed.

Introducing a save sleep mode state for an application is what this is all about. Not sure I understand your argument here.

From most of the discussion above it is clear that just saving last result of the sleep mode gesture introduces more difficulties than it solves. Therefore leaving the gesture alone i.e. keeping its behavior as a temporary override and adding GUI to manage permanent sleep mode state for applications seems to be favored by most people who have participated so far.

Not if you are in a game, want to create a profile for that game and try to solve some NVDA/game key conflicts before disabling sleep mode again.

Again gestures are not profile aware so this cannot be done whatever we do with sleep mode. It is also unclear how one should open NVDA's GUI when in sleep mode.

Actually just some examples, the native selection command or the input help command cannot be enabled via the GUI either. So if this is your argument, then there should be a separate request discussing all permanent settings should be handled both via GUI and key commands. In my view this is out of scope for this particular request and could be done in a subsequent step.

No separate request necessary since until now all permanent settings can be changed via GUI. Examples you provided aren't permanent and survive either until NVDA is restarted, the browse mode document is alive or input help is turned off.

In general when users may rely on the current behavior of the keyboard command and we can easily preserve it adding GUI for permanent change I see no reason not to. Looking at this from the different angle, why you are so reluctant to have a GUI and keep the current behavior of NVDA+Shift+S understanding this may help use ensure we haven't overlooked some important aspect.

[Adriani90]

IN case of app modules I don't know any example that enforces sleep mode by itself.

There are several in NVDA's core i.e. dosbox, doctts, cicero and some more which I haven't listed.

Ah that's very interesting to know, thanks for this catch. Nevertheless, any kind of remembering sleep mode, whether by a GUI or a key command, this question of overriding app module enforced sleep mode will come up anyway. I think if an app module enforces sleep mode, then we should look in how this is done. Is that enforced state saved anywhere?

From most of the discussion above it is clear that just saving last result of the sleep mode gesture introduces more difficulties than it solves.

I think we need more clarity on the difficulties expected in this regard. If the state is indicated by a sound or speech when switching a window to an application with sleep mode on or off, similar to what we do with focus mode or browse mode states when using alt+tab between browser and Microsoft word for example, where is the drawback there?
Ofcourse this indication should occur also when opening or closing / minimizing an application.
If we had a dedicated area where these states are saved, then we can assign a tone or speech announcement to them, at least this is my understanding.

In general when users may rely on the current behavior of the keyboard command and we can easily preserve it adding GUI for permanent change I see no reason not to. Looking at this from the different angle, why you are so reluctant to have a GUI and keep the current behavior of NVDA+Shift+S understanding this may help use ensure we haven't overlooked some important aspect.

I am not totally reluctant to the GUI aspect, but let me explain my perspective on this:
User story:

1. User opens an self voiced application (e.g. a game)
2. User turns on the sleep mode by nvda+shift+s
3. Ideally the application remembers this state and for the user it feels similar to e.g. browse mode or focus mode states in different applications because the user doesn't want to always consult the dialog in order to manage these applications.
4. The user wants to enable and disable sleep mode on the go when ever is needed. For minecraft for example this should sometimes be enabled but sometimes, when using a mod, no sleep mode is needed. However, enforcing a temporary sleep mode by NVDA is not ideal at all, neither by the current nvda+shift+s behavior.

In this case though we still struggle to find a propper GUI solution because sleep mode is not profile based, so the development process is stuck on this level.
That's why I proposed to go a step back and implement first a way to improve the current nvda+shift+s behavior by saving the application name and the sleep mode state, which will very probably solve the root problem for most use cases.
In step 2, we could open a new request and start discussing the use case for a GUI with a sleep mode management dialog. But this sleep mode management is in my view rather a consistency thing and will ofcourse improve things as well, but I think we can already solve the root problem without this GUI in the first step.
Moreover, I don't really see a convincing user story for the enforcement of temporary sleep mode setting as long as we indicate sleep mode state properly. Do you have any user story in mind?
A self voiced application will be self voiced for a very long time unless there might be an update where that doesn't work at all anymore or the user uses some mods in minecraft like in the use case I described above. But then the user should decide when to enable or disable sleep mode him or herself.

[lukaszgo1]

Ah that's very interesting to know, thanks for this catch. Nevertheless, any kind of remembering sleep mode, whether by a GUI or a key command, this question of overriding app module enforced sleep mode will come up anyway. I think if an app module enforces sleep mode, then we should look in how this is done. Is that enforced state saved anywhere?

Well it is saved inside app module, i.e. by default when the application having such an module starts NVDA goes to sleep and user can override this with a keyboard command. In my opinion we should preserve the intent, that is user choice, no matter if done via GUI or from the keyboard, should override the value provided by the app module.

I think we need more clarity on the difficulties expected in this regard. If the state is indicated by a sound or speech when switching a window to an application with sleep mode on or off, similar to what we do with focus mode or browse mode states when using alt+tab between browser and Microsoft word for example, where is the drawback there? Ofcourse this indication should occur also when opening or closing / minimizing an application. If we had a dedicated area where these states are saved, then we can assign a tone or speech announcement to them, at least this is my understanding.

Some people may rely on the fact that the change was not permanent - see below for some user stories.

3. Ideally the application remembers this state and for the user it feels similar to e.g. browse mode or focus mode states in different applications because the user doesn't want to always consult the dialog in order to manage these applications.

I'm not following this example. Without using a GUI user can enable / disable browse mode only temporarily - if they want to ensure that browse mode would be disabled they have to open the browse mode settings panel and uncheck "Enable browse mode on page load".

4. The user wants to enable and disable sleep mode on the go when ever is needed. For minecraft for example this should sometimes be enabled but sometimes, when using a mod, no sleep mode is needed. However, enforcing a temporary sleep mode by NVDA is not ideal at all, neither by the current nvda+shift+s behavior.

Once again I have trouble following this - if you need to quickly disable / enable sleep mode current gesture does what we need. On the contrary if you do not need to change the setting very often performing this via GUI is not very difficult.

In this case though we still struggle to find a propper GUI solution because sleep mode is not profile based, so the development process is stuck on this level.

Note that we can easily have a GUI which is not profile aware - most of the discussion was
focused on re-using concept of profiles, since that was suggested in the initial comment. If we decide that list of applications is saved in the base config it does not matter if applications are added via GUI, keyboard command or both of these methods.

Moreover, I don't really see a convincing user story for the enforcement of temporary sleep mode setting as long as we indicate sleep mode state properly. Do you have any user story in mind? A self voiced application will be self voiced for a very long time unless there might be an update where that doesn't work at all anymore or the user uses some mods in minecraft like in the use case I described above. But then the user should decide when to enable or disable sleep mode him or herself.

I haven't been using sleep mode very often, but when I did that was mostly when accessing virtual machines with NVDA / another screen reader using numpad / CapsLock intensively. Enabling sleep mode ensured that all keyboard commands were passed to the guest VM. Two use cases in particular:

• When using VMware KVM NVDA was intercepting all keyboard commands, so if I wanted to use NVDA gesture for NVDA in a guest VM, I had to enable sleep mode for it. I've done so via a simple app module, however very occasionally it was necessary to access VMware KVM's settings. In that case it was pretty easy to temporarily disable sleep mode from the keyboard, change whatever needed to be changed and since the change was temporary all further processes of VMware KVM were still in sleep mode
• When i was using versions of Windows affected by When using VMware Workstation 10.0.3, NVDA does not pass num pad keys through to the guest VM. #4334 I've been routinely putting NVDA into sleep mode from the keyboard for the VM window in VirtualBox, and since VM was hosted in a different process than its main GUI I could access VM settings without having to change sleep mode state at al. Note that in this case having sleep mode saved permanently would be pretty annoying, as changing settings / choosing which VM should start needs NVDA not to be in sleep mode.

While these user stories are niche, they hopefully demonstrate point I wanted to make i.e. we don't know to what extend users rely on the current behavior of the sleep mode keyboard command. Keeping it as is and adding ability to set sleep mode to be permanent via GUI ,yet overridable temporarily from the keyboard gives us the best of both words: user can make it permanent when they need to and it behaves as it used to for people satisfied with the current state.

[Adriani90]

In my opinion we should preserve the intent, that is user choice, no matter if done via GUI or from the keyboard, should override the value provided by the app module.

I agree.

I'm not following this example. Without using a GUI user can enable / disable browse mode only temporarily - if they want to ensure that browse mode would be disabled they have to open the browse mode settings panel and uncheck "Enable browse mode on page load".

That's correct for browsers, but not for things like MS Office or apps that use Chromium engines as far as I tested.
Even NVDA remembers if you enabled browse mode on an Outlook message and will open later messages in browse mode even after NVDA restart.

Once again I have trouble following this - if you need to quickly disable / enable sleep mode current gesture does what we need.

Yes, but we have to do it to often, every time when NVDA restarts. And imo that does not corespond to the reality of most users. Most people want to disable / enable it on demand without having to do it every time when opening the application or restart NVDA.

On the contrary if you do not need to change the setting very often performing this via GUI is not very difficult.

From an implementation perspective is more difficult, because a sleep mode management GUI solution is far more complex than a background storage solution of the gesture and preserving the sleep mode state in a file, whether it is the base config file or a separate ini file. I think we would come faster to a solution that would make happy most people by doing this first.

Note that we can easily have a GUI which is not profile aware - most of the discussion was
focused on re-using concept of profiles, since that was suggested in the initial comment. If we decide that list of applications is saved in the base config it does not matter if applications are added via GUI, keyboard command or both of these methods.

I agree on this, but still there were some limitation regarding to the GUI pointed out by Reef in comments above, and following are also my thoughts:

• GUI introduces dependence on translation work
• Design might change over time so probably a GUI will also have to be maintained
• The sync of list entries (aka application executables) in the dialog will need to always sync with the file where they are saved, it is a dynamic process which works for profiles but I don't know how complex that is to implement for things tied to applications directly. But it is worthy to look at it ofcourse.

In conclusion, as long as we can solve problems without GUI while preserving as much consistency as possible with other behaviors in NVDA, is in my view probably the easiest way of implementation.

• When i was using versions of Windows affected by When using VMware Workstation 10.0.3, NVDA does not pass num pad keys through to the guest VM. #4334 I've been routinely putting NVDA into sleep mode from the keyboard for the VM window in VirtualBox, and since VM was hosted in a different process than its main GUI I could access VM settings without having to change sleep mode state at al. Note that in this case having sleep mode saved permanently would be pretty annoying, as changing settings / choosing which VM should start needs NVDA not to be in sleep mode.

Thanks this use case ilustrates quite well the need for this temporary change. I also think making sleep mode tied to the process names instead of entire application doesn't really make sense.

But then the permanent behavior of nvda+shift+s could be optional, there could be a checkbox in the general settings category called "save sleep mode state" which makes nvda+shift+s permanent.
I think this way most users will already benefit from the improvement.
And the dialog for management of the temporary or permanent sleep mode on a per application basis could be done in a subsequent step.

[lukaszgo1]

That's correct for browsers, but not for things like MS Office or apps that use Chromium engines as far as I tested. Even NVDA remembers if you enabled browse mode on an Outlook message and will open later messages in browse mode even after NVDA restart.

That is not true. NVDA enables browse mode by default for all Outlook messages, unless they are currently edited. You can try this by ensuring browse mode works, disable it from the keyboard, restart NVDA and verify it is still enabled. For Chromium based applications this works similarly - make sure not to test with something like VSCode or Skype which have their own app modules enforcing that browse mode is disabled. In short it is currently a standard in NVDA that keyboard commands perform temporary changes and if you want to make them permanent then it has to be done from the settings dialog.

Yes, but we have to do it to often, every time when NVDA restarts. And imo that does not corespond to the reality of most users. Most people want to disable / enable it on demand without having to do it every time when opening the application or restart NVDA.

Note that I am not arguing current behavior is okay - merely that as long as there is alternative way of making sleep mode permanent the behavior of the gesture can remain unchanged.

From an implementation perspective is more difficult, because a sleep mode management GUI solution is far more complex than a background storage solution of the gesture and preserving the sleep mode state in a file, whether it is the base config file or a separate ini file. I think we would come faster to a solution that would make happy most people by doing this first.

This is only marginally simpler.

I agree on this, but still there were some limitation regarding to the GUI pointed out by Reef in comments above,

Please point them out explicitly - for me all of them were caused by trying to use profiles for sleep mode.

• GUI introduces dependence on translation work

Unless something changed we don't really hae to limit additions to translatable strings nor to the user guide.

• Design might change over time so probably a GUI will also have to be maintained

This is true for any new feature, where we are not sure about it being sufficient for users.

• The sync of list entries (aka application executables) in the dialog will need to always sync with the file where they are saved, it is a dynamic process which works for profiles but I don't know how complex that is to implement for things tied to applications directly. But it is worthy to look at it ofcourse.

This is trivial - listing all applications from the config is obviously simple, and NVDA stores name of the app which had focus before its GUI is shown anyway.

But then the permanent behavior of nvda+shift+s could be optional, there could be a checkbox in the general settings category called "save sleep mode state" which makes nvda+shift+s permanent. I think this way most users will already benefit from the improvement. And the dialog for management of the temporary or permanent sleep mode on a per application basis could be done in a subsequent step.

It looks like you are either against the GUI no matter what, or massively overestimating implementation difficulties. We can of course introduce additional settings in general and then try to ad GUI, but we can also add GUI which should be done anyway and have a complete feature in a single PR.

[Adriani90]

@lukaszgo1 thanks for pointing out the browse mode behavior more in detail. It made more clear to me the temporary effects of key commands in NVDA, this is not that clearly stated in the user guide.

However, it is now strange that when you disable the checkbox in browse mode settings to use browse mode on page load, browse mode is still preserved in Outlook. So the GUI element does not have any effect in this case.

I think section 6 in the user guide needs a slight rewording, including

• NVDA restores the state after restart.
• User can turn off browse mode on page load only for browsers
• App modules can enforce browse mode to be disabled by default (also applicable for sleep mode section where app modules can enforce it to be enabled)

But that's a different issue which I think I can take up to solve.

We can of course introduce additional settings in general and then try to ad GUI, but we can also add GUI which should be done anyway and have a complete feature in a single PR.

I tend to agree here now after reading this whole discussion. I think though introducing the complete GUI from the start will take more time and for a user friendly and easily maintainable solution it probably will need more UX discussion than the check box to optionally make it permanent.
I tend to close this now that we have a common understanding in favor of #16305. Or @XLTechie do you want to open a clean feature request including the questions you already answered there?