search

xtaran / XTK

Several keyboard layout designs ranging from 27% to 1800-style layouts
GNU General Public License v3.0
7 stars 1 forks source link

ISO layout variants misses the additional key right of the left Shift key #5

Open xtaran opened 5 years ago

xtaran commented 5 years ago

Reported by @FSund on Keebtalk, thanks!

xtaran commented 5 years ago

I currently see multiple possible solutions, but all have their downsides:

  1. Extend the board by 0.25u on the left side and use 1u Shift plus the <>\ ISO-specific key. This solution would have two downsides:
    • 1.25u Escape key needed. (Might be able to be substituted with a 1.25u Tab key.)
    • Would need a different (because wider) plate and PCB.
      • In theory one could try to make the ISO-incompatible XTW design (which is 0.25u wider) compatible with that layout, but supporting an alpha block with all keys shifted by 0.25u probably makes the plate very unstable. So using the XTW plate is probably not an option.
  2. Shift the according row by 0.25u to the right and reduce the left Shift key by 0.75u to 1u and right Shift by 0.25u so that this key can fit in the freed space. Downsides:
    • Uncommon stagger (same stagger as the BM43a uses and for which it got quite some bad reviews on Massdrop —eh— Drop.)
    • And again, supporting a row with all keys shifted by 0.25ueither makes the plate way more unstable or requires another plate variant.
  3. Use shorter modifier keys and put the <>\ key in the modifier row. Downsides:
    • Uncommon location for that key.
    • Only works with keycap profiles where R4 and R5 have the same profile. Exists, but is not too common. DSS seems to be such a profile.
FSund commented 5 years ago

I wouldn't really call this a bug, since that single ISO-specific key isn't that important.

Out of the solutions you listed I think 1 is probably the most feasible. Shifting the row (2) or putting the <>\-key in the modifier row is not very practical. The issue with widening the whole keyboard is of course that this deviates a lot from you original vision, so I would probably just keep everything the way it is, and map <> to a layer on the z. That's the way I usually do it on my ANSI board.

I'm impressed you remembered us ISO folks at all when designing the board, so no complaints here :)

xtaran commented 5 years ago

I wouldn't really call this a bug, since that single ISO-specific key isn't that important.

Hmm, yes, I was wondering about tagging it as "feature", too. But this had clearly the feeling of "I forgot something"...

Out of the solutions you listed I think 1 is probably the most feasible.

As long as it's just a keyboard blueprint for something which produced with a laser cutter and handwiring, this variant has nearly zero impact and is a "solution". In case this ever gets into batch production, it's probably less feasible.

So yes, that's probably the way to go for now.

Shifting the row (2) or putting the <>\-key in the modifier row is not very practical.

Ok.

The issue with widening the whole keyboard is of course that this deviates a lot from you original vision

Not really, as the original vision is to stay as close with the classic layout while making the board more compact where possible.

so I would probably just keep everything the way it is, and map <> to a layer on the z. That's the way I usually do it on my ANSI board.

Interesting. Didn't think about such a variant.

I'm impressed you remembered us ISO folks at all when designing the board, so no complaints here :)

Well, as I live in Europe, I grew up with ISO layouts. And most of my vintage keyboards have ISO layout. And in the local scene there are many who prefer local ISO layouts. :-)

But I also got accustomed to switching quickly between ISO layouts and US-English, first at university and later at work. And since I've learned early during my studies how to type umlauts on the US-English layout, I started to prefer US-English because it makes programming more easy.

And nowadays I'm lucky about that having happened, because it gives me much more choice with regards to available 3rd-party keycap sets. Which is btw. also another reason to not move keys to different rows.

Then again, moving Escape, Tab and Backspace to lower rows and reducing their size is common enough for 40% and HHKB-style keyboards to allow it for my own designs. :-)