I appreciate your efforts, Grench, but there are quite a few problems I see with your proposal:
- No dedicated dash/hyphen key (-) -- Fn+Shift+N just to get a single dash? This is a very important punctuation symbol, and it is also used to pass arguments on the shell and in coding, not just for minus but also in operators like e.g. -> and :-
- ) as Shift+( is a bad idea (also, to a lesser extent < as Shift+>). Brackets tend to come in pairs, so intuitively I expect them at the same level (primary, shifted, Fn, I don't care, but both on the same level). Same problem with { } [ ]. I want to be able to quickly type {} or () or [] and then move the cursor one back if I need to put something between the brackets (which is not always needed in coding!). That's the simplest way to make sure that your brackets are always balanced.
- Comma and period on the same key is not a good idea. They both deserve a dedicated primary key, since they're by far the most important punctuation symbols in any natural language.
- Tab as Shift+Space is a very bad idea: it has to be possible to do Shift+Tab (and, to a lesser extent, Shift+Space)
- Ctrl Lock and Alt Lock are probably not needed and just annoying to accidentally get stuck in
- I see no convenient mechanism to enter international symbols, like the German Ü Ö Ä or the Norwegian Å Ø Æ. Are you supposed to use AltGr for these? But then you lose the right Alt, so combinations like Alt+F4 become hard to do. There is no room at P+1 and L+2, Fn+vowels is already taken, I see no easy way to do implement dead diacritics, and using Compose it's going to be a lot of keypresses: you don't have any spare key that can be mapped to a dedicated Compose (no modifiers on the shoulders implies that you need all of them on both sides), so Compose would have to be something like Ctrl+Ctrl or some other combination of keys. E.g. to enter ç you would then have to press Ctrl+Ctrl, Shift+period, C (five thumb presses). On the default Pandora layout, it is Shift+Enter, Comma, C (three thumb presses since Shift is on a shoulder button). On my proposed layout, it is Shift+Shift, Comma, C (three thumb presses) using Compose, or just Pyra+Comma, C (two thumb presses) using the dead diacritic method.
Your attitude is pretty poor in your last few messages to this thread. Being condescending isn't winning you any points. At least this one actually addresses my layout instead of promoting your own. From your arguments, you clearly do not understand how this keyboard works. I'll try to walk you through it.
It's a portable keyboard with limited space. Not every key is going to get a dedicated top-level spot. It simply can't. Add in that this is designed to be used by two thumbs - not a whole set of fingers. Accepting those facts I came up with a different system that is -faster- than a shrunk down normal keyboard would be for accessing nearly all of the symbols.
- as Fn+Shift+N. That is correct, however you're making it out to be a whole lot harder than it actually is. The Fn+Shift is -chorded- together using the left thumb then the right thumb pushes N. It is no more difficult to get to then + is on a normal keyboard (shift=).
You're complaining about () both not being top level and accessible. They are easier to access on this keyboard than they are on a standard desktop.
The paired brackets on a single key using direct=( and shift+key=) is a -great- idea and allows MUCH more of the keyboard to be accessed and addressed quickly than would otherwise be available. Consider the actual action of typing (). On a standard keyboard it is shift90 = (). On my keyboard it is ( shift). Same key strokes -without moving the selector thumb-. Your left thumb is moving for the shift as the right thumb hits the ( key. I.e. its -faster- than it would be on a standard keyboard. ALL of the bracket and paired keys are faster. You can still do your () backspace one and code in the center - easy as can be. Key ( Key shift+(. The right thumb doesn't move, the left one was on it's way when you hit (. Should be very fast.
Comma and period DO belong on the same key in this layout. They are common use keys and are set to be easily accessed either straight up or with a opposite thumb shift. They're easy to find and super easy to select. Your comments keep ignoring the fact that either thumb can shift, Fn, etc... and that the modifiers can be easily chorded.
Tab as shift+space being an issue preventing shift+tab and shift+space. I have -never- seen an application that requires -anything- + tab or -anything- + space. Do you have a practical real world example of where this will be an issue? I had considered keeping the space bar split and making the left side tab and the right side space when I realized they could be merged for gorgeous symmetry on the keyboard. I can split them - but I want a hard fact real world example of why it's needed.
Ctrl Lock and Alt Lock are needed for anyone who plans to play complex PC style games on the Pyra. In fact, it's one of this keyboards great features. You would know that if you'd have bothered to read the other sections above. Fn-lock brings in the Fn and numeric keys. That's top level selection covering actions (MRPG), weapon selection (FPS) and communications. Being able to drop your thumbs down to the corners to activate Alt-Lock instantly remaps that entire section for another bank of actions. Ctrl-lock and shift-lock and all of the potential combinations is yet another set of mappings for these keys that can be input into the game configs. It's insane flexibility beyond what you get in a desktop keyboard.
As stated above, I would like to incorporate one of the color LED status lights into the keyboard design in order to display what the status is. That would make it blatantly obvious what condition it's in. As for accidentally activating Ctrl-lock or alt-lock, I find that to be a hollow argument. You'd need to accidentally without knowing push left ctrl and right ctrl at the same time to lock ctrl for instance - highly unlikely.
International symbols - I left 2 Fn and 2 Fn+shift keys which are readily available on the G & H keys for direct mapping. The right Alt can alternatively work as an AltGr, though I'm not 100% sold on it needing to. Frankly I'd rather it just be an 'Alt' key. There are 4 relatively easy to get to programmable keys. For European languages it's likely enough.
As for the ç character that you're so worried about... I don't want to seem overly callous, but why do we care so much? The odds of people who use it buying a Pandora is pretty remote.
http://en.wikipedia.org/wiki/%C3%87
On my keyboard, lock the Fn to bring up the keypad. Hold down or lock the Alt keys. Type 135 in and you'll get ç. If you use it a lot, software map it into Fn-G or Fn-shift-G or Fn-H or Fn-shift-H. The entire ASCII set can be accessed this way.
That said, I've also considered mapping shift+Fn+Enter as compose. So, Shift+Fn+Enter,c would yield ç. It would break down in strokes/actions as:
Shift+Fn with left thumb + Enter with right thumb (ONE stroke with TWO thumbs)
Shift with left thumb + , with right thumb (ONE stroke with TWO thumbs)
c with left thumb
So, a total of 3 strokes/actions of which 2 are chorded using the collected modifier pad on the left thumb.
Can you think of any reason NOT to use Fn+shift+Enter as Compose?
Would this modification meet the international keyboard need?
http://www.keyboard-layout-editor.com/#/layouts/243cbf23735f22f9022ecea6dc520efb
