Quentin,

This is another of those situations where no matter which way you'd choose to go, someone is going to be unhappy.  Even if you had a user controlled setting for "give me the full setting set all the time" versus "context sensitive" there would be users complaining that whatever default was chosen was "the wrong one."

Personally, I always prefer "the full set of options, all the time," because I'll often either start exploring, or just remembering when I see something that I'd though about looking into it and tweaking something I'd not yet gotten around to.

Others prefer the "decluttering" that comes from only presenting options that are contextually pertinent.

In the end, the end user needs to understand how the tool they've chosen (or been given or had foist upon them) works.  What's "intuitive" (and how I hate that word when it relates to almost all computer technology - were I believe nothing is truly intuitive) for one person is opaque for another.

And I'll be castigated for saying it, but there's a reason that those of us in the technology field, generally, spout the old, "RTFM!," on occasion.  Nothing is going to be entirely obvious or intuitive for any complex piece of software, and we all hit times where we have a, "How do I do that?," and/or, "This isn't working," and where either the "that" or the "this" is obvious to us, personally, in that moment of frustration.  No software maker (or product maker for anything even kinda-sorta complicate) can create something where this will never occur for any users.  And users need to be taking initiative, whether they want to or not.

There's a reason I have the following in my "stuff I have at hand to pull out and put in group postings, as often as needed," file for use in this very group:

Every NVDA user needs to know how to do two basic things when almost any question arises.  The one you want really depends on the exact nature of the question:

1.        Bring up the NVDA Commands Quick Reference:  NVDA + N, H, Q  [NVDA Menu, Help, Commands Quick Reference]

2.      Bring up the NVDA User Guide:  NVDA + N, H, U   [NVDA Menu, Help, User Guide]

The vast majority of grief and angst could be entirely avoided if doing one of those two things, or both, and then doing a simple keyword search on the what comes up were a part of every given user's routine when any given problem arises.

If only the first one were done, routinely, and a keyword search performed much of the traffic we have on this very group would vanish overnight.
--

Brian - Virginia, USA - Windows 11 Pro, 64-Bit, Version 22H2, Build 22621; Office 2016, Version 16.0.15726.20188, 32-bit

It is much easier to be critical than to be correct.

       ~ Benjamin Disraeli, 1804-1881

Hi,

For people wanting to know how input gestures dialog initially came to be (almost ten years ago), take a look at the following GitHub issue: https://github.com/nvaccess/nvda/issues/1532

Note: username "nvdakor" is me.

In short, input gestures are context sensitive for a good reason: gestures depend on where you are located, specifically system focus. To present input gestures tree view, NVDA must gather gestures from the following contexts:

1. The app you are using, whether or not NVDA itself provides support or comes with an add-on or two.
2. NVDA being told that the focused control in question require additional support (overlay classes), defined in the ap module, one or more global plugins, API-level overlay class, browse mode implementation, and other possible contexts.
3. Global plugin context - each global plugin with one or more commands (assigned or not) is treated as a separate context by NVDA, and one consequence is displaying global plugin names as separate gesture categories if defined by authors.
4. Global context powered by a set of global commands that works everywhere (or almost everywhere).

Now suppose that input gestures tree view brings all commands into view. Here is what NVDA will check:

1. Gestures defined in all (or almost all) API-level overlay classes, with some not even showing in input gestures because some controls must respond differently when pressing keys such as arrow keys.
2. Gestures from all loaded app modules, including apps you didn't even install onto your computer.
3. Gestures from all loaded global plugins provided that they are not disabled for some reason.
4. Browse mode implementations.
5. Possibly gestures assigned to all loaded braille display drivers.
6. Global commands collection.

Imagine the performance implications and conflicts that can arise as a result (conflicts being changing a command to become a global command but it can change (minimally, drastically, or fundamentally) how the command works in different contexts. It might be possible that an issue related to NVDA may turn out to be something going on with input gesture conflicts.

Cheers,

Joseph

a dialog, a don't show me this again check box and an OK button.

--

Arlene,

NVDA + F7 brings up the NVDA Elements List dialog, but it's a "grand, unified one" where the radio buttons at the top are used to dictate what element type is actually being displayed in the list below.

Quentin, here's the pertinent section of the JAWS Keystrokes reference:

--

Brian - Virginia, USA - Windows 11 Pro, 64-Bit, Version 22H2, Build 22621; Office 2016, Version 16.0.15726.20188, 32-bit

It is much easier to be critical than to be correct.

       ~ Benjamin Disraeli, 1804-1881