It's the keyboard layout.


Here's another variant, avoiding Meta+Shift for punctuation symbols, and moving Ins/Del to the action buttons:

http://www.keyboard-layout-editor.com/#/layouts/0ae20c3670099feed1b2d636a2b9eeb1


Obviously more letters get Meta-labels now, but vowels and C N S are still free of Meta-labels so the default mapping could include Ä € Ö Ü ç ñ ß, with some spare room at W, T, Y, I.
Where would you recommend putting Esc if it got moved off that row too?

The button on the left is quote/doublequote (' "), which together with Meta is dead acute / dead umlaut. Maybe it is clearer when using ◌ to indicate the dead diacritics, like this: http://www.keyboard-layout-editor.com/#/layouts/830bab21f79f40a880a15a6a1dd5b738
It doesn't seem obvious to me what is going on over there, but I don't use those.  Someone also posted a keyboard that used a dashed rectangle that I thought looked pretty good.  I don't know if something like that would make it better or worse, if it did anything at all.
 
Here's another variant, avoiding Meta+Shift for punctuation symbols, and moving Ins/Del to the action buttons:

http://www.keyboard-layout-editor.com/#/layouts/0ae20c3670099feed1b2d636a2b9eeb1


Obviously more letters get Meta-labels now, but vowels and C N S are still free of Meta-labels so the default mapping could include Ä € Ö Ü ç ñ ß, with some spare room at W, T, Y, I.
Where would you recommend putting Esc if it got moved off that row too?
Meta+Q for Esc (like on the Pandora) makes sense, Q for Quit and also somewhat top-left corner-ish. In my main proposal, Meta+Q is free; in the other ones you would have to move ~ somewhere else.

Here is yet another variant:

http://www.keyboard-layout-editor.com/#/layouts/e437557a198eb8189789b59413aa10b5

This one looks much more like the Pandora layout (or like Saber's proposal), with ,<; .>: on the left. The five dead diacritics are grouped together on Meta+TYGVB. Meta+AEIOUCNS is still free.
 
Meta+Q for Esc (like on the Pandora) makes sense, Q for Quit and also somewhat top-left corner-ish. In my main proposal, Meta+Q is free; in the other ones you would have to move ~ somewhere else.
I figured that was what you were thinking.  Thanks for the reply.
 
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.
 
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.  
 
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:

  1. 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.
  2. 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).
 
This is not going to get much love, I predict. Still, here's my take:

http://www.keyboard-layout-editor.com/#/layouts/ba190a602048622eeac97a656758e079

It's basically US-International layout with AltGr changed to Meta to avoid three Alt keys. I didn't put any labels for Meta+Letter since I think those could be defaulted to US International altgr combos but be freely reassignable. The main feature is probably the dreaded driver-level modifier Fn, that makes it possible to actually have every key on the keyboard from the software perspective, even if it's behind Fn. As far as I can tell, all shift-combos should be correct as well.

(EDIT: Tried adding numpad keys for completeness, but the site says the layout became too large. Oh well.)
 
Last edited by a moderator:
Its not a question of could happen, it _will_ happen.
 
Question, Quote, Quit, the list goes on.
 
In this post it is explained why "altGr"/F-ing-meta is flawed, why putting it on a shoulder is bad, and why following that up with shoulderMeta+Q for escape is a horrible idea.
 
The question shouldnt be left at "could" even. it "shouldnt" happen, at all. Arguing could over won't is not an exercise in suggesting could is unlikely.

Quitting out of your application because the concepts and keys are jumbled, is unacceptable. Nor is there even any benefit left, when not all keys adhere to _2-symbols per key_.
 
Left side shift doesnt actually do anything. If you get , . on the correct side, which is the right hand side, given by that, right shift is the one you need. As per mentioned a few times. See post1 and post2
 
 
Having two shifts does not make for less reliance on shoulders, its just 1 wasted key as opposed to having just the one keyboardshift.
 
Last edited by a moderator:
This is not going to get much love, I predict. Still, here's my take:

http://www.keyboard-layout-editor.com/#/layouts/ba190a602048622eeac97a656758e079

It's basically US-International layout with AltGr changed to Meta to avoid three Alt keys. I didn't put any labels for Meta+Letter since I think those could be defaulted to US International altgr combos but be freely reassignable. The main feature is probably the dreaded driver-level modifier Fn, that makes it possible to actually have every key on the keyboard from teh software perspective, even if it's behind Fn. As far as I can tell, all shift-combos should be correct as well.

(EDIT: Tried adding numpad keys for completeness, but the site says the layout became too large. Oh well.)
Nice!
 
@B-ZaR: I'll just switch Fn & . and Meta & , to be closer to the Pandora map, but of course, it's not mandatory.

I like the Fn key.
 
When ED says he'd maybe want ° on the keyboard, would that be as a diacritic or a standalone character? Trying to see if it needs a dashed circle in the layout:

http://www.keyboard-layout-editor.com/#/layouts/3242fd52a6977304857cbd7e3c096e7e

(In English, you'd only use ° as in how many degrees the temperature is, so it would be standalone. But perhaps for those languages which use it as a diacritic, it could be modified, software-wise, to give the diacritic.)
 
° as a diacritic is not very useful, you can just as well have a dedicated Å.


As for proposals with two extra modifiers (Fn and Meta like B-Zar, or F-ing and AltGr like comradekingu), I don't like that, and neither does ED. I understand the advantages: every additional modifier effectively doubles the number of virtual keys, and it is nice to have a virtual full keyboard. But I want all the important modifiers on the shoulder buttons, and there are only four of those. In B-Zar's proposal (and to a lesser extent also in comradekingu's proposal), I would really miss Fn/ F-ing as a shoulder button.
 
° as a diacritic is not very useful, you can just as well have a dedicated Å.


As for proposals with two extra modifiers (Fn and Meta like B-Zar, or F-ing and AltGr like comradekingu), I don't like that, and neither does ED. I understand the advantages: every additional modifier effectively doubles the number of virtual keys, and it is nice to have a virtual full keyboard. But I want all the important modifiers on the shoulder buttons, and there are only four of those. In B-Zar's proposal (and to a lesser extent also in comradekingu's proposal), I would really miss Fn/ F-ing as a shoulder button.
I don't understand how a Fn on shoulder will be used in games/emu that need 4 shoulders buttons.
 
° as a diacritic is not very useful, you can just as well have a dedicated Å.


As for proposals with two extra modifiers (Fn and Meta like B-Zar, or F-ing and AltGr like comradekingu), I don't like that, and neither does ED. I understand the advantages: every additional modifier effectively doubles the number of virtual keys, and it is nice to have a virtual full keyboard. But I want all the important modifiers on the shoulder buttons, and there are only four of those. In B-Zar's proposal (and to a lesser extent also in comradekingu's proposal), I would really miss Fn/ F-ing as a shoulder button.
I don't understand how a Fn on shoulder will be used in games/emu that need 4 shoulders buttons.
That's correct. Fn can't be in a shoulder button because of how it's supposed to work. I'm quite well aware of many of the downsides of my proposal, like the many, many modifier buttons, but it has its upsides too. Any layout presented here has some compromises, which are decided by avoiding breaking features considered priorities. My layout has different priorities so it breaks different features compared to the other layouts. In the end picking a layout consists of two phases: deciding the high priority features and building the rest of the layout around what must be done to achieve those. In my layout the priorities were compatibility us international -based software and an extra modifier to put any user specific behind. So if you want to make a backslash without Fn, bind it to meta+something. There's lots of space to use meta with.
 
Back
Top