More user friendly laptop keyboard layout

[nvaccessAuto]

Reported by mdcurran on 2010-08-03 03:07
I have created a branch containing a new desktop keyboard layout, that also contains alternative key bindings for laptop users. I.e. a second binding for any script that uses the numpad.
The branch is at:
http://bzr.nvaccess.org/nvda/keyboardLayoutRefactor
The advantage of unifying the laptop and desktop layouts in to one is that hopefully we will be able to maintain it much easier, and not leave the laptop layout as a "second class citizen", as some have said.
There have been a few changes to the original desktop key bindings, such as moving all the settings dialog scripts to control+nvda+function keys, to free up more keys for proper numpad emulation on the right letter keys.
Please try this new layout on laptops and provide comments on this ticket as to your thoughts:

• Are there any key combinations that do not work on your keyboard?
• Have I missed any key bindings?

If this new unified layout works well for people, I will then update the user guide with proper tables of keys and there alternatives. We also plan to mark up the user guide such that a key commands document can be generated straight from the user guide.

As a primary developer of NVDA, I am more than happy to make this new layout work well for people, and make sure its maintained as well as the original desktop layout. However, as noted above, there are some changes to the desktop layout etc, but I feel that this new way will be the most easiest for us to not leave the laptop layout behind.
Having NVDA run on laptops/netbooks is extremely important, especially in education.

I have managed to not use the alt key at all in this layout, nore have I used any 4-key combinations (e.g. control+shift+nvda+letter). As these were two problems noted in the past.

[nvaccessAuto]

Comment 1 by msuch on 2010-08-03 04:48
All this works fine in most cases.
There are still problems with combinations like NVDA+m NVDA+, and NVDA+. 7
on a french keyboard because these keys are not at the same place and in fact do not seem to be addressed this way.
So, if you want to hear previous character, current character etc, commands don't fall at the right place.
I think it would make sense to think about a localisation for kbd files.
Anyway, now we have unified key definitions and, overall, it works better than before on laptops.

[nvaccessAuto]

Comment 2 by aleksey_s on 2010-08-03 06:20
I think this change is quite controversial at least.

1. I like the idea, that NVDA mappings are easy to learn because they are well thought-out. Here I have no idea what links letter "o" (NVDA+shift+o) with "mouse tracking" option, nor I like the idea to remember order of settings dialogs in the menu to be able to activate quickly one.
2. A lot of key combinations are assigned that will be newer used by one group of users. For users with full keyboard those plenty of keys can be used in more useful way, and current code makes it available to do it differently for each group. So removal of laptop layout is a regression.
   I think that this change, while simplifying life for the developers in short-term makes life more difficult for end users. Why it simplifies only in short-term? New input framework, that was being developed by Jamie, would allow in-place assignments of keys for both desktop and laptop in one place. to add new scripts developer will be not required to go through two layout files. GUI for input action to scripts bindings will also improve experience for adding new keys, since it can check conflicts automatically and such.
   If one finds this "universal" layout convenient, i suggest to add it as a third layout and assign a maintainer for it who will be responsible for updating it and syncing with other layouts.

[nvaccessAuto]

Comment 3 by jteh (in reply to comment 2) on 2010-08-03 08:12
You make some valid points. However, let me try to clarify some of the reasons that this layout is being considered:

Replying to aleksey_s:

1. I like the idea, that NVDA mappings are easy to learn because they are well thought-out. Here I have no idea what links letter "o" (NVDA+shift+o) with "mouse tracking" option

The second letter in "mouse". We've done this a few times for accelerators which are already mapped.

nor I like the idea to remember order of settings dialogs in the menu to be able to activate quickly one.

These keystrokes are problematic because there are just way too many of them. I don't honestly understand why NVDA+n -> p -> f is so much harder than NVDA+ctrl+d, but we allowed the patch based on user demand. It follows that users who really want these will learn them, while others will just use the menu.

1. A lot of key combinations are assigned that will be newer used by one group of users.

Our understanding is that some users even on desktops actually use the current laptop keys because it makes for less hand movement.

For users with full keyboard those plenty of keys can be used in more useful way

That infers that the laptop layout will be missing some functionality. This is something we want to avoid.

and current code makes it available to do it differently for each group. So removal of laptop layout is a regression.

It isn't a regression because it doesn't remove user functionality. All commands should be available to both desktop and laptop users. It is a bug if this is not the case.

I think that this change, while simplifying life for the developers in short-term

This isn't really the primary goal. The primary goal is to come up with a layout that makes sense (the current laptop layout is really confusing in some areas and some of that is rectified in this new layout) and to ensure that laptop users can access all of the functionality available to desktop users.

If one finds this "universal" layout convenient, i suggest to add it as a third layout and assign a maintainer for it who will be responsible for updating it and syncing with other layouts.

This defeats the point. We already have enough trouble trying to keep two layouts in sync. Adding a third will only make it worse.

[nvaccessAuto]

Comment 4 by jteh on 2010-08-03 08:18
Btw, ideally, I'd prefer a unified layout which does not have any duplicates. This would require that keys that aren't present on some laptops not be used, which unfortunately includes the numpad. We have some ideas on how this could be achieved, but it would require too much code change for this release and would completely alter the experience.

[nvaccessAuto]

Comment 5 by briang1 on 2010-08-03 09:03
OK, at the moment then, this is only available to be tested on folk running from source??
Might this be important enough a change to put up a test version on the website for user comment?
The real user is the user who is not into running from source I might suggest.

I must admit i quite like the idea, it appeals to my minimalist tendencies.. grin, but its a real shame it could not have been done before everyone knew the keys in use of course.

I'm going to curse it, I'm sure as some of the presses are not entirely logical, but I'm willing to give it a go.
I note that most other readers though do have seperate mappings.
IN most cases though, in main normal use only a subset get used often.

Brian

[nvaccessAuto]

Comment by Bernd on 2010-08-03 11:17
(In #800) This ticket could be closed if #804 is implemented.

[nvaccessAuto]

Comment 7 by Bernd on 2010-08-03 11:19
Folowing scripts cannot be used by german users:
NVDA+;=navigatorObject_currentDimensions
Control+NVDA+'=navigatorObject_moveFocus
NVDA+'=review_moveCaretHere

[nvaccessAuto]

Comment 8 by aleksey_s (in reply to comment 3) on 2010-08-03 17:08
Replying to jteh:

The second letter in "mouse". We've done this a few times for accelerators which are already mapped.

Ah, OK. Anyway, something+m is more logical, if it is available.

nor I like the idea to remember order of settings dialogs in the menu to be able to activate quickly one.

These keystrokes are problematic because there are just way too many of them. I don't honestly understand why NVDA+n -> p -> f is so much harder than NVDA+ctrl+d,

Well, besides English, I am using Ukrainian and Russian layouts here, and there aren't latin letters on eastern Slavic layouts. So i need to switch layouts when I want to use menu accelerators.

1. A lot of key combinations are assigned that will be newer used by one group of users.

Our understanding is that some users even on desktops actually use the current laptop keys because it makes for less hand movement.

Some users doesn't mean the entire group of desktop users. So my point about having a lot of unnecessary duplicate bindings still applies.

For users with full keyboard those plenty of keys can be used in more useful way

That infers that the laptop layout will be missing some functionality. This is something we want to avoid.

If there are more keys, that mean there is a bigger room for convenient bindings. You are trying to equalize those, who has bigger keyboards with those, who has'nt by taking away the advantage of first ones.

I think that this change, while simplifying life for the developers in short-term

This isn't really the primary goal. The primary goal is to come up with a layout that makes sense (the current laptop layout is really confusing in some areas and some of that is rectified in this new layout) and to ensure that laptop users can access all of the functionality available to desktop users.

quoting original ticket:

The advantage of unifying the laptop and desktop layouts in to one is that hopefully we will be able to maintain it much easier, and not leave the laptop layout as a "second class citizen", as some have said.

If main point is to improve laptop layout user experience, Why not to call the unified layout the new super laptop layout and keep current desktop layout not changed then?

If one finds this "universal" layout convenient, i suggest to add it as a third layout and assign a maintainer for it who will be responsible for updating it and syncing with other layouts.

This defeats the point. We already have enough trouble trying to keep two layouts in sync. Adding a third will only make it worse.

Have you considered my argue about new input framework, which is going to allow of easier maintenance of two layouts, keeping key bindings in one place?

[nvaccessAuto]

Comment 9 by jteh (in reply to comment 8) on 2010-08-03 17:33
Replying to aleksey_s:

The second letter in "mouse". We've done this a few times for accelerators which are already mapped.

Ah, OK. Anyway, something+m is more logical, if it is available.

Agreed. Unfortunately, it wasn't.

nor I like the idea to remember order of settings dialogs in the menu to be able to activate quickly one.

These keystrokes are problematic because there are just way too many of them. I don't honestly understand why NVDA+n -> p -> f is so much harder than NVDA+ctrl+d,

Well, besides English, I am using Ukrainian and Russian layouts here, and there aren't latin letters on eastern Slavic layouts. So i need to switch layouts when I want to use menu accelerators.

Err... so how does NVDA+ctrl+ work? Isn't it the same problem?

1. A lot of key combinations are assigned that will be newer used by one group of users.

Our understanding is that some users even on desktops actually use the current laptop keys because it makes for less hand movement.

Some users doesn't mean the entire group of desktop users. So my point about having a lot of unnecessary duplicate bindings still applies.

Unnecessary to the users who don't want them, but necessary to those who do want them. That's simply a matter of perspective. You can't discount part of the user base like that.

For users with full keyboard those plenty of keys can be used in more useful way

That infers that the laptop layout will be missing some functionality.

If there are more keys, that mean there is a bigger room for convenient bindings. You are trying to equalize those, who has bigger keyboards with those, who has'nt by taking away the advantage of first ones.

Granted. However, this also means that the bindings are inherently consistent between laptops and desktops wherever possible.

I think that this change, while simplifying life for the developers in short-term

This isn't really the primary goal.

quoting original ticket:

The advantage of unifying the laptop and desktop layouts in to one is that hopefully we will be able to maintain it much easier, and not leave the laptop layout as a "second class citizen", as some have said.

So yes, it eases development, but note the "second class citizen" bit as well. Laptop users should be just as important as desktop users, so the experience should be just as good.

If main point is to improve laptop layout user experience, Why not to call the unified layout the new super laptop layout and keep current desktop layout not changed then?

Maintaining two layouts is problematic because as developers, we aren't affected by the laptop layout. As a result, it doesn't get maintained, nor does it make any logical sense when we do add new bindings.

Having one layout is less confusing because no matter what system you use, at least one of the keys for a given action will work without having to switch layouts. The key is just an "alternative" key, not a "laptop" key. This also better fits desktop users who use laptop keys to avoid excess hand movement.

If one finds this "universal" layout convenient, i suggest to add it as a third layout and assign a maintainer for it who will be responsible for updating it and syncing with other layouts.

We already have enough trouble trying to keep two layouts in sync.

Have you considered my argue about new input framework, which is going to allow of easier maintenance of two layouts, keeping key bindings in one place?

This is a very good point. However, synchronisation/maintenance is not just about keeping them in one place, though that's a good start. It's also about "understanding" the layout and ensuring that it remains logical and consistent. Also, inputFramework is quite some way off yet (definitely not 2010.2). We need a solution to this problem right now. Based on user demand, it cannot go unaddressed for yet another release.

[nvaccessAuto]

Comment 10 by briang1 on 2010-08-03 18:06
I'd suggest this change is more major than minor though so to speak, at least to some.

The real problem here is that laptops just have a shortage of keys. With the ability to get add on numeric pads, I wonder if we are worrying unduly? OK playing devils advocate a bit by saying that, but I gave up trying to use my dell without a numeric pad!

As I put in my other comment, maybe this dibate needs widening. If, though as you suggest the problem really is one of trying to get two maintained, maybe some procedural changes in how things are done might be able to help, if two people could always communicate when a new key is needed, then the new key in the other layout would always get added to the layout. The only extra would be writing it up I suppose.

The other problem which I see others are already highlighting is that on machines set up for other languages, the layout might need substantial alteration for it to work.

I still think a test version now might gain some suggestions or at least a feel for how it will be received.

Brian

[nvaccessAuto]

Comment 11 by aleksey_s (in reply to comment 9) on 2010-08-04 08:42
Replying to jteh:

Well, besides English, I am using Ukrainian and Russian layouts here, and there aren't latin letters on eastern Slavic layouts. So i need to switch layouts when I want to use menu accelerators.

Err... so how does NVDA+ctrl+ work? Isn't it the same problem?

It isn't. I can press NVDA+CTRL+ and no matter what layout is active, it will work as i pressed the letter in the English layout. Don't know how that works btw, but such behavior i have been seeing from the time i started using windows.

Some users doesn't mean the entire group of desktop users. So my point about having a lot of unnecessary duplicate bindings still applies.

Unnecessary to the users who don't want them, but necessary to those who do want them. That's simply a matter of perspective. You can't discount part of the user base like that.

The idea is that currently, users, who don't want them can disable them by switching to the preferred layout. You are eliminating this choice, forcing users, who don't want alternative unnecessary bindings to live with them.

If there are more keys, that mean there is a bigger room for convenient bindings. You are trying to equalize those, who has bigger keyboards with those, who has'nt by taking away the advantage of first ones.

Granted. However, this also means that the bindings are inherently consistent between laptops and desktops wherever possible.

It was that way before. Bindings were consistent wherever possible, differences were caused by the physical disparity where one keyboard misses a block of keys. This initiative makes bindings absolutely identical at the expense of desktop layout users.

I think that this change, while simplifying life for the developers in short-term

This isn't really the primary goal.

quoting original ticket:

The advantage of unifying the laptop and desktop layouts in to one is that hopefully we will be able to maintain it much easier, and not leave the laptop layout as a "second class citizen", as some have said.

So yes, it eases development, but note the "second class citizen" bit as well. Laptop users should be just as important as desktop users, so the experience should be just as good.

I don't see how removal of current desktop layout will benefit the users .If one works on laptop without numpad, or one prefers to use laptop layout because of other reasons, he/she will choose this in the settings. Or if you want, the automatic detecting of machine type can be implemented in NVDA which will suggest the layout. I saw this in Linux. But one, who has full keyboard and prefers to have logical rememberable bindings, will be not able to achieve this easily after removal of current desktop layout.

If main point is to improve laptop layout user experience, Why not to call the unified layout the new super laptop layout and keep current desktop layout not changed then?

Maintaining two layouts is problematic because as developers, we aren't affected by the laptop layout.

Do you mean that when universal layout were added you would change you habits and use letter navigation instead of numpad to be able to test that it is convenient for laptop users? If you both decide to do that, and you're afraid that desktop layout may be left in similar conditions, as the laptop layout is, i promise I'll stay on desktop layout to ensure it is usable. So maintenance problem will disappear :-)
On the other hand, if you aren't going to change your habits, I think that problem with laptop users stays unchanged. If none of the devs use laptop keys, no difference if he need or not need to switch layouts to try them, those bindings will stay last citizens.

As a result, it doesn't get maintained, nor does it make any logical sense when we do add new bindings.

One way I see to deal with the situation is to react quickly on the user feetback (which we always are doing well though), or may be ask community if anybody wants and can take control on laptop bindings and improve/maintain them.

Having one layout is less confusing because no matter what system you use, at least one of the keys for a given action will work without having to switch layouts.

You assume that all users must learn both layouts that are mixed now. But the old laptop layout also contained numpad bindings, and can be used for that reasons for those who need it. So again, we come to conclusion that new layout will not bring any new functionality to end-users.

The key is just an "alternative" key, not a "laptop" key. This also better fits desktop users who use laptop keys to avoid excess hand movement.

See above, laptop layout does this perfectly right now.

Have you considered my argue about new input framework, which is going to allow of easier maintenance of two layouts, keeping key bindings in one place?

This is a very good point. However, synchronisation/maintenance is not just about keeping them in one place, though that's a good start. It's also about "understanding" the layout and ensuring that it remains logical and consistent.

Again, how changing or removing the layout will change understanding? See above about developer habits.

Also, inputFramework is quite some way off yet (definitely not 2010.2). We need a solution to this problem right now. Based on user demand, it cannot go unaddressed for yet another release.

That's why i said about short-term solution. Well, we have a problem. Users report that laptoplayout is bad. let's improve it, let's teach ourselves to use it in future to not repeat this situation. Why change and worse the experience for users, who don't suffer from the initial issue?

[nvaccessAuto]

Comment 12 by mdcurran on 2010-08-04 09:08
For this release (2010.2) we will not move to this universal layout. I still believe that in the long run we can come up with a universal layout, though it may mean changing the entire paradyme to something more like voiceOver with arrow keys.
However, for this release, clearly it won't answer the problems we have.
Most likely we will go with the proposed laptop layout in #798.
The most important thing is that we also must document the laptop layout in the user guide, which I will do, as soon as we're happy with a current laptop layout.
Changes:
Milestone changed from 2010.2 to None

[nvaccessAuto]

Comment 13 by jteh on 2010-08-04 09:15
Lex, just to answer one point: I believe that a unified layout is important. I don't think that there should be two sets of bindings, as it increases complexity and learning overhead for new users. However, we need to come up with a unified layout which avoids redundancy on the main keys if we want to do this.

[nvaccessAuto]

Attachment _default_desktop.kbd added by msuch on 2010-08-04 12:14
Description:
unified keyboard file

[nvaccessAuto]

Comment 15 by jteh on 2011-12-01 08:09
People still find the current laptop layout confusing due to its use of alphanumeric keys laid out to be similar to the numpad. It also presents problems for non-English users, as certain keys aren't laid out in the same way. Also, arrow keys are easier for many people to understand.

Therefore, I propose the following layout. This may be easier for some desktop users as well. The numpad keys would be removed in this layout, which is useful for users who want the numpad to behave as it does without NVDA. I've only listed keys which are different from the current layouts. Feedback is very much welcome.

||= Name =||= Key =||
|| Toggle application sleep mode on and off || NVDA+shift+z ||
|| Report Status Bar || NVDA+shift+end ||
|| Say all || NVDA+a ||
|| Read current line || NVDA+l ||
|| Read current text selection || NVDA+shift+s ||
|| Report current object || NVDA+shift+o ||
|| Move to containing object || NVDA+shift+upArrow ||
|| Move to previous object || NVDA+shift+leftArrow ||
|| Move to next object || NVDA+shift+rightArrow ||
|| Move to first contained object || NVDA+shift+downArrow ||
|| Move to focus object || NVDA+shift+backspace ||
|| Activate current navigator object || NVDA+enter ||
|| Move System focus or caret to current review position || NVDA+backspace ||
|| Move to top line in review || NVDA+control+home ||
|| Move to previous line in review || NVDA+upArrow ||
|| Report current line in review || NVDA+shift+. ||
|| Move to next line in review || NVDA+downArrow ||
|| Move to bottom line in review || NVDA+control+end ||
|| Move to previous word in review || NVDA+control+leftArrow ||
|| Report current word in review || NVDA+control+. ||
|| Move to next word in review || NVDA+control+rightArrow ||
|| move to start of line in review || NVDA+home ||
|| Move to previous character in review || NVDA+leftArrow ||
|| Report current character in review || NVDA+. ||
|| Move to next character in review || NVDA+rightArrow ||
|| Move to end of line in review || NVDA+end ||
|| Say all with review || NVDA+shift+a ||
|| Left mouse button click || NVDA+[ ||
|| Left mouse button lock || NVDA+control+[ ||
|| Right mouse click || NVDA+] ||
|| Right mouse button lock || NVDA+control+] ||
|| Move mouse to current navigator object || NVDA+shift+m ||
|| navigate to the object under the mouse || NVDA+shift+n ||

[nvaccessAuto]

Comment 16 by mdcurran on 2011-12-01 08:30
What will happen with the synth settings ring and previous?

[nvaccessAuto]

Comment 17 by jteh (in reply to comment 16) on 2011-12-01 08:43
Replying to mdcurran:

What will happen with the synth settings ring and previous?

Damn and blast. I knew I had forgotten something. And we can't use NVDA+control+shift due to weirdness with some keyboards.

I guess we could move either object nav or settings ring to = and - and other keys. The question is which are people more likely to use more often.

[nvaccessAuto]

Comment 18 by parham (in reply to comment 17) on 2011-12-01 09:04
Replying to jteh:

I guess we could move either object nav or settings ring to = and - and other keys. The question is which are people more likely to use more often.

IMHO, people will definitely use object navigation more often. There is, however, the question of how memorable the keys are. The more it makes sense to people, the easier it would be for them to switch to the new layout. This sudden change might throw a lot of people off-balance, and they might just give up on using NVDA just because, for most intents and purposes, it is like a new screen reader to them right now. Of course, the suggested layout has its own large number of merits, which are very useful in their own right, and I personally, as a user, feel great about the change happening.

[nvaccessAuto]

Comment 19 by kevinchao89 on 2011-12-01 09:24
I think that people will use object navigation more often and it should be NVDA+CTRL+LEFT/RIGHT. Synth setting ring should be moved to NVDA+CTRL+=/-

I think that this new proposed layout will simplify, unify, and make the user experience, especially when it comes to the more advanced aspects of NVDA easier and it’s an excellent move. It will have some parity to ChromeVox and Voiceover, which some may be familiar with.

This will make object navigation, text review, mouse clicks/locks/route, and reading/reporting keyboard commands very logical, intuitive, and simple. I think that this will address the majority, if not all the concerns that people have with NVDA keyboard commands/layout. Please, this is very exciting, needs to happen, and I hope it does.

[nvaccessAuto]

Comment 20 by jteh on 2011-12-01 09:44
I know we have had problems with combinations of four keys in the past, but do we have any particular reason to suspect that NVDA+control+shift+arrows will be a problem? That would be the cleanest solution to the synth settings issue and it should probably be at least tested before we discard it. They certainly work on my system.

[nvaccessAuto]

Comment 21 by briang1 on 2011-12-01 10:28
Personally, I'd hate to have a lot of the keypad keys and others moved at this stage, though understanding the ethos here, I do think some extra effort on consulting via other lists etc, might be a good idea before anyone does anything.
I being a desktop keyboard user feel the current set is fine of course. I generally find using laptops a pain in any case so if forced to plug in another keyboard!

I like the ability to use the sayall with no focus movement on the big plus key on thekeypad too.
Its actually the same key as Hal uses of course.

So, please ask widely on lists before going with this. It might indeed upset a lot of existing users.

[nvaccessAuto]

Comment 22 by jteh on 2011-12-01 10:32
I think the existing desktop layout would continue to exist, as many users find they are more efficient using the numpad. I see this more as a replacement for the laptop layout, which is currently far harder to understand than the desktop layout.

[nvaccessAuto]

Comment 23 by parham (in reply to comment 20) on 2011-12-01 10:37
Replying to jteh:

I know we have had problems with combinations of four keys in the past, but do we have any particular reason to suspect that NVDA+control+shift+arrows will be a problem? That would be the cleanest solution to the synth settings issue and it should probably be at least tested before we discard it. They certainly work on my system.

I personally have no trouble with this. I can just lay my left pinky on all the three keys and switch, but that's me. Of course, one could also hold capslock plus the right shift and right control keys.

But then again, I think - and = are better. Leaving nvda+shift+ctrl and right/left/up/down for another review feature that might be added in the future might be a better move. This is impacting every single user, and the goal is to make them as comfortable as possible.

Plus, I don't know how non-English keyboards work, and people talking on this ticket are all advanced computer users and programmers, and long-time NVDA users. I have no idea at all how a newbie would take to this approach.

[nvaccessAuto]

Comment 24 by pvagner on 2011-12-01 10:43
I can remember I had issues with four keys being pressed at the same time on a laptop but currently combos such as NVDA+control+shift+arrows are working fine for me.
Other four key combinations such as attempt to press letters SDFJ while using braille emulation keyboard result in three key press only. So I think this is a valid exception which we should make some good use of.

[nvaccessAuto]

Comment 25 by jteh (in reply to comment 23) on 2011-12-01 10:55
Replying to parham:

I personally have no trouble with this. I can just lay my left pinky on all the three keys and switch, but that's me. Of course, one could also hold capslock plus the right shift and right control keys.

I was referring to the fact that some keyboards actually cant' handle certain key combinations with four keys for some odd reason.

But then again, I think - and = are better.

They don't make as much sense, though. I guess you could have NVDA+-/NVDA+= to decrease/increase setting and NVDA+shift+-/NVDA+shift+= to select the setting. Will this be memorable enough for newbies? Also, are there keyboards for any locales where - and = aren't unshifted keys?

I have no idea at all how a newbie would take to this approach.

The goal is to make it easier to follow than the current laptop layout. I think most less experienced users would agree that arrow keys are easier to understand than trying to pretend the alphanumeric keys are a numpad.

[nvaccessAuto]

Comment 26 by pvagner on 2011-12-01 10:59
Also a quick review to the proposed layout.
Only the commands which have 'z', 'and '' in them are currently a problem for me.
keys 'z' and 'y' are swapped on some types of slovak keyboard layout. Though this can be used to. It's the same like french keyboard has letter 'a' swapped with some other key I think. I think this is not an error and we can see this just as a warning.

However the other combinations might really be a problem. 'coresponds to 'ú' and '' coresponds to 'ä'. These are accented characters so are not available in other layouts. In order to type 'or '' (curly braces) I need to press the right alt key reffered to as the alt-gr key what NVDA handles as 'ctrl+alt' in combination with letter f. so commands such as NVDA+control+[ and NVDA+control+] won't work this way. I think these will apply to other keyboard layouts as well.

[nvaccessAuto]

Comment 27 by jteh (in reply to comment 26) on 2011-12-01 11:10
Replying to pvagner:

keys 'z' and 'y' are swapped on some types of slovak keyboard layout. Though this can be used to.

I don't think this is a problem. Letters in different places are only a problem if we're relying on the location of the key, which we're not in this case. I just picked z because it's often associated with sleep. :)

However the other combinations might really be a problem. 'coresponds to 'ú' and '' coresponds to 'ä'.

Damn. That's definitely a show stopper. Maybe NVDA+9 and NVDA+0? Failing that, NVDA+f3 and NVDA+f4 might work, though that seems a bit weird to me for some reason. Any other ideas?

[nvaccessAuto]

Comment 28 by orcauser (in reply to comment 25) on 2011-12-01 11:16
Replying to jteh:

Also, are there keyboards for any locales where - and = aren't unshifted keys?

For the swedish layout, equals is shifted.
shift+0

[nvaccessAuto]

Comment 29 by briang1 (in reply to comment 22) on 2011-12-01 11:27
Replying to jteh:

I think the existing desktop layout would continue to exist, as many users find they are more efficient using the numpad. I see this more as a replacement for the laptop layout, which is currently far harder to understand than the desktop layout.Yes, I agree. I'm also wondering about the loss of possible extra combinations this might introduce for the future.

[nvaccessAuto]

Comment 30 by jteh (in reply to comment 28) on 2011-12-01 11:30
Replying to orcauser:

For the swedish layout, equals is shifted.

Damn. Okay, so NVDA+control+shift+arrows is looking like the best option for settings ring.

[nvaccessAuto]

Comment 88 by surveyor (in reply to comment 87) on 2012-12-10 09:18
Replying to jteh:
Because of the gestures using left and right brackets, the turkish locale gestures.ini file should be modified. I've already done. Attaching for possible inclusion of this new layout.

[nvaccessAuto]

Attachment gestures.ini added by surveyor on 2012-12-10 09:20
Description:
turkish locale gestures for distribution

[nvaccessAuto]

Comment 89 by jhomme on 2012-12-10 13:01
Hi,
I am for putting this into a snapshot and seeing how positive the feedback is. I think that a write-up explaining the merits of the layout from the user point of view would help. As I was reading the comments about how people don't like the fake number pad thing, I realized that I had no trouble with it because I had a previous experience with a DOS screen reader a long time ago. I purposely went into learning NVDA with an open mind, though, so maybe I was at an advantage. I think that using keys that use letters like l for line are easy enough to remember, and it seems natural to use arrow keys for navigation instead of letters on the keyboard, so to repeat myself, I say let's try it.

[nvaccessAuto]

Comment 90 by jteh (in reply to comment 89) on 2012-12-10 21:42
Replying to jhomme:

I am for putting this into a snapshot and seeing how positive the feedback is.

It's already available in a snapshot branch. If you think there are users who should be testing this, feel free to pass this info on.

[nvaccessAuto]

Comment 91 by Brendon22 on 2012-12-19 07:12
Hello,

I really like this new Laptop layout for NVDA, and it also fixes the problem I have with Changing the Voice settings, and NVDA's other settings on the fly, very nice!

[nvaccessAuto]

Comment 92 by ondrosik on 2012-12-22 16:34
I just tested the new layout and I have a few comments. First some things to Userguide as this is my source for new shortcuts (I noticed later that new shortcuts were posted in this ticket, but this may help to repair things)
Move mouse to current navigator object and Enable mouse tracking have the same shortcut - nvda+shift+m in userguide, the correct one for Enable mouse tracking is nvda+m.
Follow System Focus is nvda+ctrl+7 in userguide, the correct seems to be nvda+7 as in desktop.
Progressbar output in the userguide the nvda+ctrl+f2 is mentioned, correct is nvda+u.
Synth settings ring is nvda+ctrl+shift+arrow keys, the old one e. g. nvda+ctrl+arrows is mentioned.

One question:
How to click and lock the left and right mouse button? I am using the Slovak keyboard layout. It also doesn't work when i set the English keyboard layout. It just don't work and NVDA says just "left bracket". I also noticed when tracking this issue that when using the input help, i get the slovak name of those keys also when English keyboard layout is set. Do we need a local gesture file, e. g. something which was posted for Turkish keyboard?

[nvaccessAuto]

Comment 93 by Bernd on 2012-12-24 12:04
I created a gestures.ini for German but wasn't available to use the + sign which replaces the ] sign on German keyboards. Please see ticket #2898

[nvaccessAuto]

Attachment gestures_sk.ini added by ondrosik on 2012-12-26 17:16
Description:
Slovak gestures file for new laptop keyboard

[nvaccessAuto]

Comment 94 by jteh (in reply to comment 92) on 2013-01-03 06:54
Replying to ondrosik:

First some things to Userguide as this is my source for new shortcuts (I noticed later that new shortcuts were posted in this ticket, but this may help to repair things)

Thanks for reporting. Fixed in changeset:newLaptopLayout,5618.

How to click and lock the left and right mouse button? I am using the Slovak keyboard layout.

Is this fixed by the gesture map you attached?

It also doesn't work when i set the English keyboard layout.

I don't understand why it wouldn't work for English. Have you had any further luck with/thoughts about this?

[nvaccessAuto]

Comment 95 by ondrosik (in reply to comment 94) on 2013-01-03 11:50
Replying to jteh:

Is this fixed by the gesture map you attached?

yes, it works fine.

I don't understand why it wouldn't work for English. Have you had any further luck with/thoughts about this?

Really not, I am switching between slovak (sk) and English (UK). When slovak (sk) is selected, In input help mode I am getting numbers but for slovak keyboard there are specific keys like ľ, š, č, ť... but for example ô is presented as ô whether the keyboard is Slovak or not.
So NVDA+[ is still nvda+ú. It seems that something is really broken in my system locale settings but no idea what's going on. Maybe Peter or Pvagner are following this ticket.

[nvaccessAuto]

Comment 96 by ondrosik on 2013-01-09 20:15
I have a little suggestion for Userguide. Do we need a separated laptop column in certain sections if both are the same for whole table? I mean Voice Settings, Braille settings, Keyboard Settings, mouse settings, Review Cursor Settings, object presentation settings, browse mode settings, saving and reloading the configuration? For example
Name
Desktop key
Laptop key
Description
Use screen layout
NVDA+v
NVDA+v
This option allows you to specify...
I know that this is more related to Userguide, but now we are changing the laptop layout so this should be probably discussed too.

[nvaccessAuto]

Comment 97 by Bernd on 2013-01-12 11:56
I think it would be more logical if we would use NVDA+Shift+L for report current line in review.

[nvaccessAuto]

Comment 98 by jteh (in reply to comment 97) on 2013-01-14 01:00
Replying to Bernd:

I think it would be more logical if we would use NVDA+Shift+L for report current line in review.

The problem is that this breaks consistency with reporting of words and characters. This is also only logical for English speakers. While we have other commands like that, I was trying to avoid this for the basic review commands.

[nvaccessAuto]

Comment 99 by jteh (in reply to comment 95) on 2013-02-01 01:30
Replying to ondrosik:

I don't understand why it wouldn't work for English. Have you had any further luck with/thoughts about this?

Really not, I am switching between slovak (sk) and English (UK). ... for example ô is presented as ô whether the keyboard is Slovak or not.

This might be fixed by 6bbcbbd.

[nvaccessAuto]

Comment 100 by ondrosik (in reply to comment 99) on 2013-02-01 06:50
Replying to jteh:

This might be fixed by 6bbcbbd.

yes, i forgot to check it out after update, now it detect input lanauage correctly also when input help mode is enabled.

[nvaccessAuto]

Comment 101 by jteh on 2013-02-04 05:19
Merged in b92a0a7.
Changes:
State: closed

[nvaccessAuto]

Comment 102 by surveyor (in reply to comment 101) on 2013-02-05 07:54
After merging this branch into the main, I couldn't use the locale gesture commands that were usable previously. I've already attached the file including these gestures for turkish locale. I'm getting this error when I pressed the keys set for leftMouseClick, leftMouseToggle and rightMouseToggle. Error is below:
ERROR - keyboardHandler.internal_keyDownEvent (09:48:44):
internal_keyDownEvent
Traceback (most recent call last):
File "keyboardHandler.pyc", line 146, in internal_keyDownEvent
File "inputCore.pyc", line 282, in executeGesture
File "baseObject.pyc", line 34, in get
File "baseObject.pyc", line 110, in _getPropertyViaCache
File "inputCore.pyc", line 100, in _get_script
File "scriptHandler.pyc", line 110, in findScript
File "scriptHandler.pyc", line 47, in _getObjScript
UnicodeEncodeError: 'ascii' codec can't encode character u'\xa0' in position 21: ordinal not in range(128)

[nvaccessAuto]

Comment 103 by norrumar on 2013-02-06 17:14
Changes:
State: reopened

[nvaccessAuto]

Comment 104 by norrumar on 2013-02-06 17:19
In spanish keyboard layout, [ and ] are recognized as GRAVE and plus keys, so it is not possible to use left and right mouse buttons with the new laptop keyboard.

[nvaccessAuto]

Attachment gestures.2.ini added by norrumar on 2013-02-06 17:23
Description:
This file fixes the reported bug for international spanish keyboard

[nvaccessAuto]

Comment 105 by MHameed on 2013-02-06 18:32
Thanks committed as f7290ab

[nvaccessAuto]

Comment 106 by jteh on 2013-02-06 22:25
For further issues regarding this, please file new tickets. Thanks.
Changes:
State: closed

[nvaccessAuto]

Comment 107 by drein on 2013-02-07 08:50
for Italy, we need the same fix of spanish, because instead of [ and ], we have è and + symbol.
thank you.