Screen curtain should not automatically toggle off when switching configuration profiles

[Neurrone]

Steps to reproduce:

1. Assign the screen curtain command to a gesture.
2. Turn on screen curtain while in the default profile. It doesn't matter if its only temporarily or permanently on while NVDA is active.
3. Switch to an app which would cause a different profile to load, e.g one for programming.

Actual behavior:

The screen curtain is automatically disabled when switching to an application which uses a profile where screen curtain has not yet been enabled. Users also receive no alerts about this surprising and potentially dangerous behaviour. The only way to know is to visually see the screen.

Expected behavior:

The screen curtain should not automatically disable itself when switching profiles. I think this is a setting which makes much more sense to be global to avoid unwanted surprises. I'm also not sure what the use case is for having it automatically turn on only in certain applications, which the current implementation enables.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

alpha-19136,0124e647

Windows version:

1905

Name and version of other software in use when reproducing the issue:

N/a

Other information about your system:

N/a

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

N/a

[LeonarddeR]

This is an interesting point. Cc @feerrenrut

While I think there might be potential for having screen curtain enabled only in certain profiles/applications, I think what you're raising here is actually broader than just screen curtain. The active providers are saved in a list. This means that, if you have screen curtain enabled in one profile and then disable it in another, then enabling the nvda highlighter in the default profile, the highlighter will also be off in that other profile.

I see several solutions:

1. Making the vision section a global config parameter. I think this is problematic though. While valid for the screen curtain may be, I can think of reasons why one wants the highlighter on in certain situations or hide the highlight in some other situations. Also if a magnifier would be integrated into the vision system, we have to deal with different color schemes / magnification levels
2. Giving every provider an enabled boolean in its own config section. This ensures that changes for a provider's activity in a certain profile won't touch other providers.

Additionally, we might want to make the provider announce its enabled/disabled state when the state is toggled by a config profile switch.

[Neurrone]

@LeonarddeR I think that having the disabled state announced would mostly address the privacy concerns here, and I agree that per-profile settings are appropriate for most vision providers. Not sure if there are any other cases like this where being global is more desirable.

[Neurrone]

Wondering if an intermediate solution could be implemented in time for the release of 2019.3 to address the potential privacy concerns? E.g, an announcement when the screen curtain gets automatically toggled off.

[LeonarddeR]

After thinking about this a little more, I really want to keep the possibility to switch on the Screen Curtain on for some profiles and of for others.

[Neurrone]

It sounds like there is a lot of design work that will take time.

I suggest as an intermediate solution just announcing when the curtain gets automatically switched off? This addresses the immediate privacy concerns, without committing to a design for how vision providers interact with profiles.

[feerrenrut]

An interim solution has been merged (to beep when screen curtain enables / disables). I think this could be solved by looking at what caused the screen curtain became enabled. If screen curtain is enabled via gestures, it should override (but not modify) the profile. Though note, the opposite is not true, if screen curtain is disabled by a gesture, a new profile trigger should be able to enable screen curtain.

If we accept that behavior, we also must consider whether state change by gestures should be saved to the config at all. Perhaps there should be different behavior between temporary and permanent screen curtain gestures?

[feerrenrut]

I'm removing the 2019.3 milestone and leaving this issue open. I think the immediate concern is resolved, but there is more to discuss.

[Adriani90]

A solution would be to implement two shortcut for the screen curtain like

1. Enable screen curtain for default profile
2. Enable screen curtain for all profiles.

These shortcuts would solve most concerns and would most probably fulfil every expectation from users.