Then you have the problem of accidentally meta+q-ing. Shoulder-operation of anything is not obvious.
Lets say you want to write a big Q, and mistake shift for meta, when they are on the same side shoulders.
Thats the end of your application, and the start of a bad relationship with the keyboard.
I don't think it's a huge problem. You don't really need capital Q very often (at least not in most languages), so I don't think that that particular accident is likely to happen. Still, why make Esc only a secondary Fn/Meta key if we have enough keys to make a dedicated primary Esc key, in a location close to its normal location (very top-left), safe from accidental presses but still easy to access.
Then you have the problem of accidentally meta+q-ing. Shoulder-operation of anything is not obvious.
Lets say you want to write a big Q, and mistake shift for meta, when they are on the same side shoulders.
Thats the end of your application, and the start of a bad relationship with the keyboard.
There's a bunch of
coulds that may happen with the keyboard. Probably a rarer one there comradekingu, but they'll always be something to tradeoff. Not to toot my own horn here, but this is why we should quell our overreliance on the shoulder buttons, as I've done in my proposals v2(revision) and v3(ignore the lowest row's centered spacebar for a moment as it pertains to this discussion), and why two Shift keys and
maybe two AltGr keys(as shown with v3)
on the keyboard might be a good plan.
Shoulders as backups ideally, at least where Shift and AltGr values are concerned. Tab as one of the smaller face buttons(the lower one like I have it in my other v3 layout in my sig) and Escape where Menu is(with Menu on AltGr + Spacebar). These are some options to ponder.
Three shift keys (two on the keyboard, one as a shoulder button) is problematic. Three Fn/Meta keys is problematic for the same reason. Modifiers come in pairs, and that's what standard software expects: L_SHIFT and R_SHIFT, L_ALT and R_ALT, L_CTRL and R_CTRL, L_META and R_META. They do not come in triplets. So if you want to have three shift keys, there are only two options:
- invent a new keycode (say, S_SHIFT, for Shoulder Shift), and configure xkb etc to make it behave exactly like a Shift key. The problem is that lots of software will not recognize it (because it is not a standard key), so it will be hard to map game functions to it etc.
- map two different physical keys to the same keycode, e.g. left keyboard shift to L_SHIFT, right keyboard shift to R_SHIFT, shoulder shift also to R_SHIFT. This means it is impossible to distinguish those two keys (e.g. shoulder shift and right keyboard shift). This also means it becomes possible to have 'impossible' sequences of key events, e.g. two [R_SHIFT DOWN] events following one another without a [R_SHIFT RELEASED] in between, which will cause some software to get confused.
Also, we have a keyboard with
less keys than a normal full keyboard, so if you ask me, it makes no sense to make it have
more redundant duplicate keys.
Shoulder modifiers are not just a "backup option", they will be the main modifiers for most users. ED is a notable exception. Shoulder buttons are an
extremely nice mechanism to implement modifier keys, it is arguably more efficient than how it is done on a normal keyboard, so it is definitely something we should optimize for. Although I agree that there should be a backup option in case you can't easily use the shoulder buttons (like when the Pyra is sitting on a table).
