It's the keyboard layout.


Here's v4.0c as described in the post prior to this: 

(layouts v4.0a and v4.0b are in my sig)

Kind of like this one. 

RNDtSdH.png
Misaligned number row is not so nice.

Why not put Esc all the way on top? Much less risk of accidental presses, and should still be quite easy to reach...
 
Here's v4.0c as described in the post prior to this: 

(layouts v4.0a and v4.0b are in my sig)

Kind of like this one. 

RNDtSdH.png
Misaligned number row is not so nice.

Why not put Esc all the way on top? Much less risk of accidental presses, and should still be quite easy to reach...
Why not put Escape up top you ask? It's because it'd be all the way up top, far removed from the other keys. Has it's good and bad points.  

As for the misalignment, that's disputable. On many keyboards, the Escape key is to the left of the F-keys F1-F12. This is how it is on the keyboard I'm using at present. Here, underneath the Escape is the Backtick and Tilde key, and just to their right is the number row, starting with number 1, which begins directly underneath F1.

In this latest mockup, it aligns perfectly, here, but to repeat myself, I'm not inflexible with these layouts, and we could put barely useful ` in that top left corner, and totally useful ~ as it's Shift value, with Escape under Fn. Something like this.
 
Here's v4.0c as described in the post prior to this: 

(layouts v4.0a and v4.0b are in my sig)

Kind of like this one. 

RNDtSdH.png
Misaligned number row is not so nice.

Why not put Esc all the way on top? Much less risk of accidental presses, and should still be quite easy to reach...
Why not put Escape up top you ask? It's because it'd be all the way up top, far removed from the other keys. Has it's good and bad points.  

As for the misalignment, that's disputable. On many keyboards, the Escape key is to the left of the F-keys F1-F12. This is how it is on the keyboard I'm using at present. Here, underneath the Escape is the Backtick and Tilde key, and just to their right is the number row, starting with number 1, which begins directly underneath F1.
Escape at the very top, far removed from the letters and numbers, that is where it usually is on normal keyboard.

The misalignment I was talking about is between the number row and the QWERTY row: normally "2" should be between "Q" and "W", not between "W" and "E". Comradekingu's layout has the same issue. It is perhaps not a huge issue, but if we can keep the alignment correct, it's still better.

This is how a normal full-size US-QWERTY keyboard looks: http://www.keyboard-layout-editor.com/#/layouts/29c5176552f79c65bca1f66beb18441a

Of course we don't have enough keys for that, so we have to make a selection.

If you would map things back to a normal keyboard, things would look as follows:

This is v4.0c of Saber's proposal: http://www.keyboard-layout-editor.com/#/layouts/9fe5ad40a0c7ca16e24c3f3ede30ac13

This is my current proposal: http://www.keyboard-layout-editor.com/#/layouts/afb73cddfab87ce624273982fcbb9bcd

(I have indicated the keys I consider "correctly aligned" in white, and the ones that are "misaligned" in black).
 
Last edited by a moderator:
But you are flat out skipping buttons to make it happen. Preserving alignment between numbers and letters, and then skipping letters, for purpose of being a "normal" keyboard is creating more issues than it solves.
 
But you are flat out skipping buttons to make it happen. Preserving alignment between numbers and letters, and then skipping letters, for purpose of being a "normal" keyboard is creating more issues than it solves.
I'm not skipping US-QWERTY letters. I am skipping German and Scandinavian letters, just like I'm skipping some US-QWERTY symbols, because something has to be removed when you go from 104 keys to 67 keys, and I'd rather remove üöä / åøæ as primary keys than some of the other keys. But I agree that this is a matter of priorities and I understand that other people have different priorities than me.
 
skimming posts from email I've only just had chance to look at Saber's graphics

OMG no, no, no, a thousand times no!!! what were you thinking....!

You're just pulling our legs because you want to see 100 pages aint ya?
 
Here's 5.0.

A few things first: 

  • Symbols € and ° may be removed for dead diacritics if the Acute isn't the only one we'll have. For this, as I've shown previous, I envision ß moves to Fn + L which gives us breathing room to place certain dead keys like Circumflex, Dead Grave, and/or Umlaut.
  • Left Shift can still move over to where keyboard Right Shift is, if ED is okay with only a single Shift keyboard key. As it is in 5.0, Left Shift by my understanding conciliatory would be remappable. I know this isn't the most ideal but both single and double keyboard Shift proponents get something of measure out of it. 
http://i.imgur.com/uW5O3e2.png

uW5O3e2.png
 
Last edited by a moderator:
LOL I knew you were pulling out legs - much nicer! ;)

Why not have R Shift on the right and L Shift on the left ?....

why have right shift on the left trigger why not left shift?
 
OK, here is one more attempt to do something "comradekingu-style", with P+1, L+2 available for locale-specific stuff:

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

By default, P+1, L+2 have ' " , < . > and their Meta actions are 6 dead diacritics (as indicated by the dotted circles ◌), for acute, umlaut, cedilla, caron, dot and circumflex.

In a language-specific configuration, you would lose those diacritics (the idea being that you don't need them if you speak a language that just needs three extra letters at P+1 and L+2), and you get to choose:

  • Either you have language specific letters (Ü Ö Ä, or Å Ø Æ, for example) in those spots as dedicated, primary keys, and have the original punctuation symbols behind Meta
  • Or keep the punctuation symbols as dedicated keys and have the language specific letters behind Meta (so not at the primary layer, but at least in the correct spots)
You still get to keep a dedicated keyboard Meta, Shift and Tab whatever you do.

Otherwise, this proposal has the same features as my previous proposal, except that Tab is now in a weirder place, Shift and Meta are no longer neighbors, ` ~ has been replaced by ' " as a dedicated key, and the number row is no longer correctly aligned to the QWERTY row.
 
LOL I knew you were pulling out legs - much nicer! ;)

Why not have R Shift on the right and L Shift on the left ?....

why have right shift on the left trigger why not left shift?
Wanted to keep it consistent with the Pandora where Right Shift is on L1. Due to some concerns mentioned, I thought it "safer" to not have the Right Shifts on opposite extremes to prevent them from simultaneously being pressed(in case this causes some software to implode). A small advantage too is Left Shift can(I think) be remapped without affecting the Shoulder Shift(if we will have two keyboard Shift keys). :)   
 
Last edited by a moderator:
I'd rather have just one shift a shoulder and just one on the keyboard. 1+1=2 not 3 !!!

Just because the Pandora did it one way, does that mean it shall for always be done only that way...?
 
I'd rather have just one shift a shoulder and just one on the keyboard. 1+1=2 not 3 !!!

Just because the Pandora did it one way, does that mean it shall for always be done only that way...?
That's fine. Whatever will be.  :)

Wanted to mention, Fn values on Y, G, V, and B could be rotated around a little with ~ to B, \ to Y, | to G, and maybe _ to V. 

Second bit is { [ ] } could become { } [ ]. We shall see.
 
Last edited by a moderator:
Saber, when you post your keyboard layouts, could you please also add a link to it so those of us coming from email notifications can have something to click on? I don't mind coming to the forum, but it would be nice to have something more direct, especially when reading on mobile.
 
LOL I knew you were pulling out legs - much nicer! ;)

Why not have R Shift on the right and L Shift on the left ?....

why have right shift on the left trigger why not left shift?
Wanted to keep it consistent with the Pandora where Right Shift is on L1. Due to some concerns mentioned, I thought it "safer" to not have the Right Shifts on opposite extremes to prevent them from simultaneously being pressed(in case this causes some software to implode). A small advantage too is Left Shift can(I think) be remapped without affecting the Shoulder Shift(if we will have two keyboard Shift keys). :)   
I have attempted pressing both left and right Shift keys simultaneously on both my laptop and desktop and so far neither have degenerated into a raging ball of plasma, or in any other way self destructed. Does there actually exist software that dislikes having both left and right Shift keys pressed together?
 
LOL I knew you were pulling out legs - much nicer! ;)

Why not have R Shift on the right and L Shift on the left ?....

why have right shift on the left trigger why not left shift?
Wanted to keep it consistent with the Pandora where Right Shift is on L1. Due to some concerns mentioned, I thought it "safer" to not have the Right Shifts on opposite extremes to prevent them from simultaneously being pressed(in case this causes some software to implode). A small advantage too is Left Shift can(I think) be remapped without affecting the Shoulder Shift(if we will have two keyboard Shift keys). :)
 I have attempted pressing both left and right Shift keys simultaneously on both my laptop and desktop and so far neither have degenerated into a raging ball of plasma, or in any other way self destructed. Does there actually exist software that dislikes having both left and right Shift keys pressed together?
The issue isn't with one right shift and one left shift.

The issue is that Saber has decided to forego all standards and the collective wisdom of the forum and place TWO right shifts AND a left shift in his layouts. Three shifts with two 'right shifts' on the keyboard itself.

The concern isn't with pressing left and right shift together. It is in how software will behave when right shift and duplicate right shift are both present and used. Applications that make decisions based on the press and or release of the right shift key could theoretically get confused.
 
OK, here is one more attempt to do something "comradekingu-style", with P+1, L+2 available for locale-specific stuff:

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


By default, P+1, L+2 have ' " , < . > and their Meta actions are 6 dead diacritics (as indicated by the dotted circles ◌), for acute, umlaut, cedilla, caron, dot and circumflex.


In a language-specific configuration, you would lose those diacritics (the idea being that you don't need them if you speak a language that just needs three extra letters at P+1 and L+2), and you get to choose:

  • Either you have language specific letters (Ü Ö Ä, or Å Ø Æ, for example) in those spots as dedicated, primary keys, and have the original punctuation symbols behind Meta
  • Or keep the punctuation symbols as dedicated keys and have the language specific letters behind Meta (so not at the primary layer, but at least in the correct spots)
You still get to keep a dedicated keyboard Meta, Shift and Tab whatever you do.

Otherwise, this proposal has the same features as my previous proposal, except that Tab is now in a weirder place, Shift and Meta are no longer neighbors, ` ~ has been replaced by ' " as a dedicated key, and the number row is no longer correctly aligned to the QWERTY row.
Will acute be possible with with this layout? Anyways, very sexy!
 
Back
Top