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 https://github.com/nvaccess/nvda/issues/3721#issuecomment-447488121
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.

[lukaszgo1]

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.

While I personally share your concerns what you're proposing is quite different to what @feerrenrut proposed. Would it be possible for you to discuss this and agree on a single UX which would be accepted by NV Access so that this issue can be progressed?

Perhaps a solution could be to save the sleep mode state as with any other option,

Again it seems this has been declined by @feerrenrut. They said:

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.

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

When activating the sleep mode with the keyboard command NVDA reports "sleep mode on" for me. Is it not working for you?

Or an earcon like screen curtain uses.

We still need to provide an alternative way of signaling this to the user - don't forget people working with braille only. Also creating an earcon is not an easy task - I've no idea how all sounds which were using now were created.

[feerrenrut]

Is the sleep mode setting intended specifically for profiles triggered by an application, or is it anticipated to also be triggered manually?

I'm not sure it makes sense to trigger a "sleep mode" profile manually.

[lukaszgo1]

Is the sleep mode setting intended specifically for profiles triggered by an application, or is it anticipated to also be triggered manually?

I personally don't see any use case for the latter. If "sleep mode" would become a setting which can be saved in a profile I see two options when activating the profile manually:

• Assume that user knows what they're doing and activate sleep mode anyway or
• Activate sleep mode only if the profile was triggered i.e. exclude cases when it is activated manually.

[XLTechie]

Edit: I wrote the below, before seeing the bulk of the thread (even my own earlier comments), because of some partial page load (or something). So it was written out of context, without realizing that no changes were preferred to the profile dialog.

I propose the following:

1. Add a "remember sleep mode in this profile" checkbox to the profile creation screen. This should be on by default. Edit: it occurs to me that it should be a three way radio or combobox: Always start in sleep mode, Remember last sleep mode state, and Ignore sleep mode. This allows users to run applications that should be in sleep mode most of the time, but require leaving sleep mode in order to close properly. This would let them continue to start in sleep mode, even if they have to leave it before they close the program.
2. When an app is entered, and it has a triggered profile:
   • Make all changes that the profile would normally make first, if any.
   • Lastly, turn on sleep mode for the app.
3. If sleep mode is activated in an app:
   • turn on sleep mode.
   • Check whether the app has a profile.
     • If not, auto-generate one, and save sleep mode in it.
     • If so, and the profile's "remember sleep mode" flag is set, add sleep mode to it.
4. If the user turns off sleep mode in an app:
   • Turn off sleep mode.
   • If the current profile is a sleep mode auto-generated profile, delete the profile.
   • If the current profile is set to "remember sleep mode", remove sleep mode from the profile.

This requires, probably:

• adding an auto-generated flag (and parenthetical name) to system-generated profiles; and
• that profiles remove the auto-generated flag, any time a user change is made to the profile, so it can not later be deleted. The latter covers corner cases which I'm not sure can exist.

[marrie]

I think that the temp profile is a good idea in combination with the sound/alert or both. if the temp profile will then become permanent there needs to be a way to alert the user of this as well.

[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 https://github.com/nvaccess/nvda/issues/3721#issuecomment-1080156673 and this https://github.com/nvaccess/nvda/issues/3721#issuecomment-1082779956 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.