The big Pyra keyboard poll

[_wb_]

This thread is another wall of text, looking at latest proposal, it isn't centred, ctrl looks to be in a hardish to reach place, and space appears to not be big and central. I have tried to at least scan through the posts in this thread, and sounds like a lot of well thought out and researched solutions but still the "stick with what I know" in me is questioning if I would rather keep the current Pandora layout... moving some of the keys around for symbols I can see making sense.

How do you want to implement a central space? Shove it between V and B ?

Ctrl on a shoulder button (the same one as on the Pandora) should be easy enough to reach.

A centered layout is possible, but it implies collateral damage for international layouts.

 

[_wb_]

Here is the final version of my proposal:

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

The above is language-neutral, it has no language specific. Here are two examples of what the unmapped Pyra-keys could be used for:

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

French: http://www.keyboard-layout-editor.com/#/layouts/5df09faf7ea721d2c034b1796057696a

 

[Wally]

Dunno if we need the multimedia key labels considering we're not going to look at those keys to change stuff. Kinda defeats the purpose

 

[_wb_]

Dunno if we need the multimedia key labels considering we're not going to look at those keys to change stuff. Kinda defeats the purpose

I agree, we don't need them as labels. I just put them there to make it clear what those buttons do when you use them with Super, not what the actual labels should look like. There is no room for all of that on the actual labels, and it would not be very useful either.

I would make the actual labels look something like this:

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

 

[Grench]

Dunno if we need the multimedia key labels considering we're not going to look at those keys to change stuff. Kinda defeats the purpose

I agree, we don't need them as labels. I just put them there to make it clear what those buttons do when you use them with Super, not what the actual labels should look like. There is no room for all of that on the actual labels, and it would not be very useful either.

I would make the actual labels look something like this:

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

For consistency the labels on the right game pad should match in case/tense.  Either the PU/PD/Home/End symbols should be low and gray or the Del and Ins lettering should be bright white.

I'm a bit fearful for a lot of the layout examples based on whether that space bar is going to be one double-wide key or two 'normal' keys to be mapped.  ED hasn't committed to splitting it in two.

 

[klapse]

Here is the final version of my proposal:

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

The above is language-neutral, it has no language specific. Here are two examples of what the unmapped Pyra-keys could be used for:

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

French: http://www.keyboard-layout-editor.com/#/layouts/5df09faf7ea721d2c034b1796057696a

This is pretty darn good. Though I still like the idea of a double width spacebar, this layout makes good use of the extra key and is very easy to remember/learn.  Also I like that language-specific umlauts etc are not labeled on the keys.

 

[Askarus]

Dunno if we need the multimedia key labels considering we're not going to look at those keys to change stuff. Kinda defeats the purpose

I agree, we don't need them as labels. I just put them there to make it clear what those buttons do when you use them with Super, not what the actual labels should look like. There is no room for all of that on the actual labels, and it would not be very useful either.

I would make the actual labels look something like this:

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

Like it but I dislike how the Pyra button is used.

It should be used as the Pandora button and not be a modifier.

As a Modifier we want to use AltGR, so that's on the shoulder button already.

Why is Shift on the lower right of the Keyboard?

I would like to have it where ' and " is and have the modifier on the lower right position (AltGR).

There is so much room on all the buttons that ' and " don't need to b e on an extra button I think.

For now it's not planned to use Pyra as modifier key, but AltGR.

There needs to be a modifier on the keyboard as well.

 

[fusion_power]

Here is the final version of my proposal:

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

The above is language-neutral, it has no language specific. Here are two examples of what the unmapped Pyra-keys could be used for:

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

French: http://www.keyboard-layout-editor.com/#/layouts/5df09faf7ea721d2c034b1796057696a

I could live with that german layout, not bad.  maybe changing it to QWERTZ but QWERTY is also OK. At least this layout looks much more usable than the Pandora layout where I still searching for certain buttons after all the time. 

I hope the Pyra will come with different language specific layouts.

 

[_wb_]

Dunno if we need the multimedia key labels considering we're not going to look at those keys to change stuff. Kinda defeats the purpose

I agree, we don't need them as labels. I just put them there to make it clear what those buttons do when you use them with Super, not what the actual labels should look like. There is no room for all of that on the actual labels, and it would not be very useful either.

I would make the actual labels look something like this:

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

Like it but I dislike how the Pyra button is used.

It should be used as the Pandora button and not be a modifier.

As a Modifier we want to use AltGR, so that's on the shoulder button already.

Why is Shift on the lower right of the Keyboard?

I would like to have it where ' and " is and have the modifier on the lower right position (AltGR).

There is so much room on all the buttons that ' and " don't need to b e on an extra button I think.

For now it's not planned to use Pyra as modifier key, but AltGR.

There needs to be a modifier on the keyboard as well.

The Pyra button (the one below SELECT) is intended to work just like the Pandora button: if you press it, the main menu pops up. That does not mean it cannot also be used as a modifier (just not as a sticky one).

Tab and Shift are interchangeable in my proposal.

The R2 shoulder button is just Right Alt in my proposal. You can use it as AltGr if you want (if you need an extra layer of symbols for some reason), but by default it's just a normal Alt modifier. So e.g. to produce Alt-F4, you would have to press L2+R2+4.

I wouldn't want to give up ' " as a dedicated key, for two main reasons:

1. They're used quite a lot in both natural language and coding: in English, both ' and " occur more frequently than the letters J, Q, X, and Z, more frequently than all of the numbers, more frequently than ; : ! ? = ( ) { } [ ] < > + \ | / ` ~ @ # $ % ^ & *.

2. They're used for two of the most important diacritics: acute accent and umlaut. For example, I speak Dutch, which means I occasionally need ä ë ï ö ü and á é í ó ú. Not very frequently (not like ü ö ä in German), just a one or two times per paragraph or so. The only way to input them that makes sense is using the Compose key or using dead diacritics. Both are simpler when there's a dedicated key for ' " (so I can use Pyra+' for acute and Pyra+" for umlaut).

Here is the final version of my proposal:

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

The above is language-neutral, it has no language specific. Here are two examples of what the unmapped Pyra-keys could be used for:

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

French: http://www.keyboard-layout-editor.com/#/layouts/5df09faf7ea721d2c034b1796057696a

I could live with that german layout, not bad. maybe changing it to QUERTZ but QUERTY is also OK. At least this layout looks much more usable than the Pandora layout where I still searching for certain buttons after all the time.

I hope the Pyra will come with different language specific layouts.

My example was with the assumption that there's one keymat for everyone (so you just have to remember that the umlauted letters are at Pyra+UOA and ß is at Pyra+S). If there's a special keymat for German, you can of course make something closer to a standard German QWERTZ keyboard, not just swapping the Y and Z but also putting ÜÖÄ at their normal spot, changing the shifted number row symbols, etc.

 

[klapse]

The Pyra button (the one below SELECT) is intended to work just like the Pandora button: if you press it, the main menu pops up. That does not mean it cannot also be used as a modifier (just not as a sticky one).

Sorry if this is a stupid question, but if the Pyra button functions to bring up the menu, how can it be used as a modifier? The menu would pop-up before you could press the other key.

 

[_wb_]

The Pyra button (the one below SELECT) is intended to work just like the Pandora button: if you press it, the main menu pops up. That does not mean it cannot also be used as a modifier (just not as a sticky one).

Sorry if this is a stupid question, but if the Pyra button functions to bring up the menu, how can it be used as a modifier? The menu would pop-up before you could press the other key.

Just like how it is done in Ubuntu for a few years now: the menu pops up only when you release the button, not when you press it, and only if you don't press any other key between the button press and the button release. So you can distinguish a button "tap" (press and release without doing anything in between) from a button "hold" (when using it as a modifier).

In the default Ubuntu (Unity), when you tap Alt, you get a HUD command prompt (like what you get with Alt-F2 in many other OS's), and when you tap Super (the Windows key) you get the Dash Home. You can still use Alt and Super as a modifier: e.g. in Ubuntu, Alt+Tab is used to switch between applications, Super+T is used to open the Trash, etc. We can do similar things with our START, SELECT, PYRA and SUPER buttons: if you tap them, they do something (I propose double click, middle click, main menu and context menu respectively), but you can also use them as a modifier.

The only thing that we can't do then is have them behave as sticky modifiers.

 

[slaeshjag]

Also, if we have that button on the shoulder, it can't really be used in games, can it? Since it'll open the menu all the time?

 

[double7]

What should the function of the action buttons be?

I think i'll remap them to - and / for standard shell command line usage.

 

[_wb_]

Also, if we have that button on the shoulder, it can't really be used in games, can it? Since it'll open the menu all the time?

I wouldn't make the shoulder buttons behave in the same way as the corresponding Shift, START, SELECT, PYRA buttons. They would be Right Shift, Right Alt, Right Ctrl, Right Pyra (which would perhaps actually be Right Meta or Right Hyper as far as Linux is concerned), while the keyboard versions would be the Left ones.

On this laptop, the Left Alt opens the Ubuntu HUD, while the Right Alt I use as a Compose key. It's no problem to use the two modifiers in a different way.

As for what happens when you tap e.g. START in a game: should this register as a double click or just as LALT keypress+keyrelease events?

I suppose this should be handled in some way. It's basically the same problem as the one with the nubs: are they mouse or joysticks? I suppose it depends on the game/application what functionality is most useful. My suggestions apply only for the general "desktop" kind of use pattern; in games, everything is a bit different anyway, and controls have to be customized anyway in some way.

 

[_wb_]

The design looks reasonable ... I also like that the lower buttons go around the edge. Not sure if one will still press both buttons when trying to hit the upper ones, but it looks a lot more like what I would have expected.

Could turn out to be a vulnerable spot though, looks like the entire corners are basically a hole now, filled with the buttons. Still worth a try though.

It looks better from the outside. And It does not need to go that far around the lower edge, I just used the Pandora trigger as base but to get more stability, the Pyra lower trigger may be a little bit smaller there, whatever works better without weakening the case. Same for the distance in between the triggers, may be larger than here to have more case material in between and separate them more:

Maybe the smaller buttons could bet set as alt and ctrl by default.  In particular I'm very interested to be able to have access to a Tab and ` character for being able to efficiently use Canonical's Unity DE.  People in the Debian camp have been working on supporting Unity since 14.04 when they finally changed the forked package names from the original Gnome names.  I think that Unity would be great on it as it utilizes the vertical space very efficiently.  I hope that we could get a functional tab, and ` on the keyboard.

For backwards compatibility, it makes sense to make the big shoulder buttons be Shift and Ctrl like on the Pandora. The small ones can then be Alt and Pyra/Fn/Meta/Sym/AltGr/howeveryouwanttocallit.

A dedicated backtick key is probably asking too much -- I had it in some of my earlier proposals, but the key is just not important enough to deserve that.

But what about this:

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

Now Backtick is at Pyra+Tab, which means that the default keybindings of Unity would be: R2+Tab to switch between applications (or R2+L1+Tab to go in the opposite direction), L2+R2+Tab to switch between windows of the current application. That kind of makes sense, no?

(Also, tilde on Pyra+Q is above backtick on Pyra+Tab, so it's a bit like the normal key where Shift+backtick gives tilde).

 

[_wb_]

Can the double-width space key proponents please make a suggestion as to which key they would like to sacrifice in order to get a bigger space key?

E.g. in my current main proposal:

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

you could easily get a bigger space bar by getting rid of the keyboard Shift or dedicated Tab key...

 

[SNESFAN]

again with the greek? .... I mean really? Was having a good time answering questions till I got to that.

As long as it resembles a standard laptop's qwerty layout minus the space possition, I'm totally cool with it regardless of button placement or label placement.

The extra positional preference crap such as shoulder/action button additional functions should be user configurable or changeable via a system option without any kinda markings. Actual keys being marked is important for key placement or identifying which button makes the screen brighter/darker or turns off radios etc.

 

[comradekingu]

Its also important for things like sane defaults. Unless you have a compelling reason to mark it differently that is.

 

[_wb_]

I think we should have as many markings as possible. If there are four shoulder buttons and six action buttons, it helps a lot to indicate what they actually do: mark them as Shift, Ctrl, Pyra, Alt, Home, End, PgUp, PgDn, Ins, Del instead of just L1, R1, L2, R2, A, B, Y, X, etc.

There are a lot of Pandora users who don't even know that the shoulder buttons are modifiers and the action buttons are Home/End/PgUp/PgDn, or who only realized that after a while. Let's not make the same error again.

 

[sebt3]

There are a lot of Pandora users who don't even know that the shoulder buttons are modifiers and the action buttons are Home/End/PgUp/PgDn, or who only realized that after a while. Let's not make the same error again.

If they cant read the manual, that's *their* problem...