Hi,

Also, when I do git diff between this branch and origin/master, I get submodule commits.

Thanks.

@josephsl wrote:

Also, when I do git diff between this branch and origin/master, I get submodule commits.

I'm sorry but I can't find any.
Are you sure your in sync?

@josephsl wrote:

Er, I'm a new user of NVDA. Is NVDA+Shift+T listed in commands quick reference?

You're definitely right.
I'm currently traveling. I'll add documentation impact when I get to the hotel tonight.
Thanks.

this shortcut conflicts with the instant translate layer.

@LeonarddeR wrote:

this shortcut conflicts with the instant translate layer.

IMO this should not be assigned by default. It is useful only for a tiny minority of users.

@LeonarddeR wrote:

this shortcut conflicts with the instant translate layer.

This add-on indeed binds nvda+shift+t
Looking for an alternative, it appears the "translate" add-on by @yplassiard in turns binds nvda+control+shift+t.
I'm not aware of the "Instant Translate" user base, but "translate" has already gained some significant popularity in the French community and I'd prefer thus avoid conflicting.

@lukaszgo1 wrote:

IMO this should not be assigned by default. It is useful only for a tiny minority of users.

I agree there are probably currently more user interested in translation oriented add-ons than they are in this global command.
Still, we can reasonably expect touch interaction to become more of a wider concern in the future, as it seems modern user interfaces keep on evolving this way. (Sure, I miss old text terminals...)
My preferred policy remains on providing default bindings as much as reason allows - It has already proven being a great advantage when providing support and trainings, especially compared to SR like Jaws which comes with localized bindings.

Hence, I'd propose nvda+alt+t, unless off course a contrary consensus arises.

@josephsl wrote:

Er, I'm a new user of NVDA. Is NVDA+Shift+T listed in commands quick reference?

@feerrenrut wrote:

Can you please add the gesture to the userguide. Under the "Enable touch interaction support" section.

Both done as of 7eccadb
Note this also fixes the in-doc link to the "Enable touch interaction support" setting as there was an extraneous space between "#" and "TouchSupportEnable" in the anchor specifier.

By the way, we might consider adding more of the default touch gestures to the Commands Quick Reference document, as well as finding some way to move the NVDA Touch Gestures section further down the document.

nvda+alt+t is already used by the addon time zoner
https://addons.nvda-project.org/addons/timeZoner.en.html

how about ctrl+alt+nvda+t?

Imo we should discuss if it does not maybe make sense to introduce a second layer for addon? i.e. pressing nvda+alt+spacebar activates the second layer and after that one key stroke will be processed. The second layer could be only dedicated to scripts and commands introduced by addons. The first layer is reserved only for commands in the NVDA core.

Otherwise at a certain point we will end in a situation where you need more than 5 fingers to execute a command :))

@JulienCochuyt wrote:

@lukaszgo1 wrote:

IMO this should not be assigned by default. It is useful only for a tiny minority of users.

I agree there are probably currently more user interested in translation oriented add-ons than they are in this global command.
Still, we can reasonably expect touch interaction to become more of a wider concern in the future, as it seems modern user interfaces keep on evolving this way. (Sure, I miss old text terminals...)

While the fact that touch screens are getting more and more popular cannot be argued with what makes this command not very interesting for many people is the fact that even on a touch screen pc it adds value only for partially sighted users.

Hence, I'd propose nvda+alt+t, unless off course a contrary consensus arises.

Sounds reasonable.

@lukaszgo1 wrote:

what makes this command not very interesting for many people is the fact that even on a touch screen pc it adds value only for partially sighted users.

A blind user might also benefit from this feature in the case of a full screen UI with a usable native touch interface.
We already have different examples of these with musical instruments or game apps in the IOS ecosystem.
I'm sure identical examples for Windows won't last to arise, if not already out there.
I'm limiting this example to full screen, because IIMNW Windows currently lacks the ability to define a control as needing to be kept away from AT touch interception, like IOS does. Btw, we might need in the future to try implement such a concept, to allow app modules to give back proper usability of such UI.

@XLTechie wrote:

We should not just default to the next available most simple gesture, but should consider how likely most people are to want it there, especially in the light of gesture needs of the future.

Agreed.

why not make the default gesture be something more obscure, like NVDA+Alt+Ctrl+T, or NVDA+Ctrl+Windows+T. Using NVDA+Alt+T, keeps that three finger command from being used in the future for something more useful to more people, thus forcing something more useful on to a more unwieldy gesture.

My preference, if we decide for a 4-fingers gesture, would go for NVDA+control+alt+t, because:

• NVDA does not currently have default bindings involving the windows key, at least to my knowledge
• It is easier to type on a keyboard with no left windows key, like found on many laptops. Note that the left alt key is missing from some keyboard layouts, replaced by alt gr. which emulates control+alt, leading to a 3-finger gesture.

@Qchristensen, waiting for your feedback please regarding wording in the documentation.

@feerrenrut, what do you think regarding the debate on the default gesture? Shall we go for nvda+control+alt+t?

I agree with Reef's suggestion re changing the wording in globalCommands.py from "Toggles on and off the support of touch interaction" to "Toggles support for touch interaction". Otherwise, wording all looks good.