Allow excluding a key stroke from a profile in input gestures dialog

[Adriani90]

Dear all,

most users of NVDA use CTRL+NVDA+F to search something in browsers due to the fact that the cursor does not jump to the results when using the native search functions built in browsers. However, some people are used to CTRL+F and want to keep this keystroke for searching. So they change the gesture in the input dialog but it applies globally which causes conflicts in some programs. For example in MS Outlook where CTRL+f stands for "forward message".

There are many other examples. My suggestion is to allow setting profile based gestures.

Comments are appreciated.

[Adriani90]

As a workaround people can attribute different keyboard layouts to profiles and assign different gestures for a function. But this is not ideal because in most cases it's just about few gestures.

[LeonarddeR]

I'm one of these users who has overridden ctrl+f to USE NVDA's search facility. For me, it is enough to either disable browse mode before pressing control+f, or passing the key through with nvda+f2. In my opinion, it would be a bit too much to create profile specific input gestures just to cover the use case as described above.

[Adriani90]

Well, this is just an example. If we consider addons and possible conflicts (i.e. sentence nav and MS Outlook where alt+down arrow is in conflict with two functions) then profile based gestures make sense. There is also an addon for MS Word provided by French community where some key strokes are in conflict with NVDA key strokes. Profile based gestures would make it easier to solve such conflicts.

Von: Leonard de Ruijter notifications@github.com Gesendet: Montag, 26. März 2018 16:13 An: nvaccess/nvda nvda@noreply.github.com Cc: Adriani90 adriani.botez@googlemail.com; Author author@noreply.github.com Betreff: Re: [nvaccess/nvda] Allow profile based gesture assignments in input dialog (#8123)

I'm one of these users who has overridden ctrl+f to USE NVDA's search facility. For me, it is enough to either disable browse mode before pressing control+f, or passing the key through with nvda+f2. In my opinion, it would be a bit too much to create profile specific input gestures just to cover the use case as described above.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/8123#issuecomment-376179978 , or mute the thread https://github.com/notifications/unsubscribe-auth/Aaon8clLZuoWWy8HQnsAG1VZKiVQfBx3ks5tiPdRgaJpZM4S6KZC . https://github.com/notifications/beacon/Aaon8QhlXHgXsx8w-GJizaYEOeWb6Btnks5tiPdRgaJpZM4S6KZC.gif

[jscholes]

On the NVDA add-ons mailing list, someone just asked if it's possible to bind a specific gesture only under certain circumstances, e.g. when Notepad is running. I think it's fair to say that many users, rightly or wrongly, could assume that the phrase "configuration profile" applies to all aspects of config, of which preferred gestures are undoubtedly a part. It's disappointing that instead, the word "configuration" has a very specific and non-obvious meaning, applying only to those items in the "Settings" dialog and synth settings ring but not to input gestures, speech dicts and symbol pronunciation. People shouldn't need to write add-ons to accomplish tasks like:

1. binding app-specific gestures to avoid conflicts;
2. using app-specific speech dictionaries; and
3. customising specific aspects of punctuation on a per-app basis (e.g. for development or proofing work).

The answer to the poster's question, therefore, is no. Not unless you know how to write Python to such a degree that you can develop an app module that emulates other gestures, modifies key bindings at runtime on app focus/blur, etc., or set up a per-app keyboard layout which is hardly flexible.

[cary-rowen]

I also think that the individual configurations created by NVDA are not perfect and very limited. The configuration of the reading dictionary has been PR, but there has been no new progress.

[seanbudd]

I think having independent input gesture profiles is probably a better idea rather than tying them to applications. We kind of already support this internally with laptop/desktop. If we let people make custom input gesture profiles it could be like: laptop, desktop, document editing, web browsing, etc. That way these are not tied to specific applications (e.g. Chrome or Firefox) and more universal for the tasks being performed (e.g. web browsing).

[XLTechie]

@seanbudd But the use case I most often here, is for specific applications.We just recently had a discussion on the NVDA list, where a user had a gesture conflicting with professional audio editing software, and wanted to disable that gesture only in that software, where it wasn't needed anyway.

Far less often do I hear of someone needing to have custom gestures that work across a range of applications ('all browsers', 'all editors'). Of course that's just what users I am exposed to, and I'm sure there are some who would prefer this option.

But the longevity of this feature request suggests this is the preferred outcome, does it not?

[seanbudd]

@XLTechie I struggle to envision a UX for this suggestion as is, particularly with the existence of laptop/desktop configurations making this more complex.

[XLTechie]

@seanbudd wrote:

I struggle to envision a UX for this suggestion as is, particularly with the existence of laptop/desktop configurations making this more complex.

I can think of two.

1. As implied by @jscholes in https://github.com/nvaccess/nvda/issues/8123#issuecomment-879549804, we cause the Input Gestures dialog to work like the config dialogs do (other than General), when a profile is active. In that case, any gestures changed are stored only in the profile. I think this is the most ideal, and user familiar, interface UX.
2. As an alternative, we place an "Edit input gestures" button in the profile dialog, active when editing/adding a profile. It would open an Input Gestures dialog identical to the main one, but applicable for that profile only.

Store the gestures in profiles\PROFILE NAME-gestures.ini.

[XLTechie]

Actually, I answered for UI, not necessarily UX.

I think the only UX issue that is not UI related is: remapping a desktop gesture that has a laptop counterpart or vice-versa.

There are two ways to go that I can conceive:

1. If a script has any gesture overridden, void all gestures for that script and apply only the ones from the profile.
   • E.g. if Laptop is set by the profile, but desktop is not, desktop layout has no gesture for that script. Same as would happen if the gestures for that script were all deleted in Input Gestures, and only one was created to replace.
   • If an "all" gesture is created, void all and replace all, as if the gestures for the script were cleared, and a replacement "all" was created.
2. Override only the gesture in the layout overridden, and leave the other alone unless it, too, is overridden.
   • In that case, an all gesture would be additive.

Edit: Same rules if a gesture is removed?

The more I think about it, the more I think option 1 is the most logical UX.

If the user wants to remove NVDA+T as a default gesture in a profile, it is highly likely that laptop and desktop versions should need to be specifically assigned after that in that profile. Otherwise, it may be impossible to delete certain key assignments (I think).

If the user removes the non-specific version of NVDA+T in a profile, but a laptop or desktop version of NVDA+T exists in the global profile, I think that removal may be counteracted. I'm not entirely sure whether that's accurate at the moment.

[Adriani90]

2. As an alternative, we place an "Edit input gestures" button in the profile dialog, active when editing/adding a profile. It would open an Input Gestures dialog identical to the main one, but applicable for that profile only.

Is that not too complex? Actually the root problem is that NVDA cannot exclude input gestures from a profile / application. It is simpler when interpreting it this way. So I rather propose adding a checkable list to the gestures, dialog where people can choose from which profile the gesture should be excluded.

1. In the input gesture dialog, focus an assigned gesture
2. Press tab twice, after the "remove" button, there could be a list populated with all current profiles, all are enabled by default
3. Disable the profiles you don't want the gesture on.

Advantage:

• No issue with duplicates
• Less complex in the implementation
• Less risk for confusions

[Adriani90]

But the use case I most often here, is for specific applications.We just recently had a discussion on the NVDA list, where a user had a gesture conflicting with professional audio editing software, and wanted to disable that gesture only in that software, where it wasn't needed anyway.

In that case the user could create a profile for that application and exclude the gesture from it like I proposed in the previous comment.

[XLTechie]

@Adriani90 you said:

Advantage: • No issue with duplicates

Can you explain this more? What has the potential to be duplicated in any of these ideas? I do not follow this.

• Less complex in the implementation

I'm not sure where you see the complexity in my two ideas:

• In my suggestion 2, which you quoted, it needs only the addition of a button to the create/edit profile dialog. Then, it needs some logic in the existing gestures dialog, to make its action applicable only to the selected profile (that is an overview of the effect).
• In my suggestion 1, even less, as the existing input gestures dialog needs the ability to detect only, and indicate in its title, that it's editing a profile. That would make it very consistent to what users already expect with NVDA's settings panel's handling of profiles. No new GUI controls required. This idea is better IMO.

With your idea, I see one very big problem:

If all profiles are checked by default, meaning that all gesture changes apply to all of them by default: what happens if the user unchecks all profiles (including the global profile), and only leaves one profile checked? The gesture will only apply in that profile, yes? However what if a new profile is added to NVDA? By default, it should be checked, the next time the user opens the profile chooser, since checked is the default state.

• But if it is checked, that means that as soon as it was created, NVDA has to go through all other profiles, find their customized gestures, and apply them to this new profile.
• How does it handle conflicts?
• Would the user really expect that outcome?

I think it is far more likely that the user wouldn't expect the new profile to be checked by default, and wouldn't expect the gestures from all other profiles to be applied to the new one. But that means that this is a change of behavior for the profile chooser list of the Input gestures dialog: at first all are checked by default, but as soon as you un-check one, the default is now un-checked. I see much more user confusion in that.

Better to apply the same paradigm used with NVDA config panel, to the existing Input gestures dialog.

More on complexity:

I believe your solution and mine, once you leave the UI aspect, have the exact same back-end.

Let's say the user wants to override the infamous NVDA+T for one application's profile, e.g. Audacity.

• In your solution: user opens Input Gestures, goes to e.g. Read Status command, and adds NVDA+T. Then he tabs to the profile selection list, and un-checks every profile, including the default/global profile, except for Audacity.
• In my solution 1: he switches to the Audacity profile, opens Input Gestures, goes to Read Status command, and adds NVDA+T.

Either way: NVDA will now write an audacity-gestures.ini file in the profiles directory. It puts this new gesture in that file.

Hereafter, every time Audacity profile is triggered, the audacity-gestures.ini file is loaded, and NVDA+T is assigned to read status bar, instead of read title bar.

When the profile is changed, the gesture is reverted to whatever it was before. This requires some logic to keep a list of overridden gestures, and their states in various profiles, in memory. In effect, the gesture must be virtually overridden for every profile, including global, in order to reset it every profile change. But that must be done in every solution I am pretty sure.

[Adriani90]

Let's say the user wants to override the infamous NVDA+T for one application's profile, e.g. Audacity.

That is the thing, the root problem is not to override the gesture for an application, but but to exclude the keystroke from that profile.

In my solution 1: he switches to the Audacity profile, opens Input Gestures, goes to Read Status command, and adds NVDA+T. Either way: NVDA will now write an audacity-gestures.ini file in the profiles directory. It puts this new gesture in that file. Hereafter, every time Audacity profile is triggered, the audacity-gestures.ini file is loaded, and NVDA+T is assigned to read status bar, instead of read title bar.

This does not corespond to the root problem I described above. What you describe is overriding a gesture, which is a different problem and needs a separate discussion. I am requesting here only a way to exclude keystrokes from the profile, so that the native key stroke of the application or the keystroke provided by an add-on for the application remains. That's why I gave the example with ctrl+f between outlook and the search / NVDA find feature. I understand your idea, but it is overly too complex for what I requested here originally in my view at least.

[XLTechie]

But @Adriani90, from NVDA's prospective, technically, excluding a gesture is the same as remapping that gesture to "None".

The exact same infrastructure is required to cause a profile to ignore a specific gesture, as there is to remap that gesture to another key. And all of the same concerns and difficulties.

You can prove this now, by looking at your gestures.ini file. Then, remove an existing gesture that NVDA sets by default, and look at gestures.ini again.

Additionally, the title of this issue is to "allow profile based gesture assignments". So that is what I talked about as the primary focus.