It's the keyboard layout.


Too late when you discover what it does. Also,

  • The keyboard should be standard enough to be used by every normal user.
To illustrate the problem. in mupen64plus, pressing escape does this.

Core Status: Stopping emulation.
Core: R4300 emulator finished.
Core Status: Rom closed.
 

And thats the end of your game. Emulator terminated, no questions asked. If you want to change this, its in a textfile. And what if you actually want to be able to press escape? Where do you put it then? Where something else is? Where do you then put that?  For other programs this is a recursive remapping-problem.

"you can just" doesn't work in practice. Put escape, as a dedicated key, in a position where it doesnt have a need to be moved. Its a discussion that has been covered already, and many valid points were raised. It also proved to be popular in the vote http://boards.openpandora.org/topic/16868-the-big-pyra-keyboard-poll//URL]

Btw, forget about meta functionality to do anything, it doesnt work, i've always had to tell people how that works. Some of the hardest geeks know already, but thats the threshold. The more it is relied upon, the more stuff is taken out of the realm of "i can just pick this up and do this"

Ideally it should be even easier than:
post-2326-0-50253200-1411634451.png


Euros and especially americans, dont understand how regular third level modifier works. Euros might know the exact way to input an @, but thats about it.

Typical point of failure is to understand AltGr works like shift does for the other numbers that dont produce @. Same with dead-keys.  AltGr+compose is something

i learnt just recently, because i have very little use for it. If googling a word known to include said special character once every very seldom is easier than figuring out how a keyboard really works, even if its a real keyboard, often fails.

The ones who dont doubletap caps-lock to type big letters also understand shifted letters and also shifted number-row. Thats the basis one can work from, since it facilitates a working paradigm.

From working with user-support and localization, people aren't the problem, less than fully intuitive designs are.
 
Last edited by a moderator:
I don't think Escape in Saber's layout is in a position that would be easily accidentally hit.  But for people who are very concerned, they can modify the code if they find themselves "all thumbs" ;) .
 
Anyways, hope you and others like them in a preliminary sort of way.   :)
I do think you have a nice layout in general, and I appreciate your taking the time to do modifications based on community input :) .  It's looking extremely polished.

I'm looking at one of the dedicated Esc maps you have... 

I really like this, except that I feel like you moved ", ', ?, and / around worse from an earlier layout.  I would have kept ' and " on A and S, / and ? on Z and X, respectively.  (Alternatively, you could do ? and / on Z and X, which would make /= an easier combo ;) .)  This way things are "closer" to each other (horizontal relationships are less jarring than vertical relationships, IMO).

For the same reasons, I would also want backtick and forwardtick together, and \ and | next to each other (horizontally).  But I don't use either ticks very much, and I don't often pipe things, so it's not that important for me.  It does make certain keys harder to reach, which may not be as happy for some people.  And maybe the changes have been made for certain other reasons, which I missed in the intervening discussion...

Also for people who are worried about escape being too close to something, just change what it does in the given program.
In the v3 versions, ? and ' are purposely on AltGr + comma and period because they are infrequently(not at all?) used in DOSBox/QEMU's terminal from what I've skimmed. I think so anyways. :unsure:   :)   
 
Last edited by a moderator:
Updated all the layouts with one small, yet crucial change:

  • CAPS Lock is now at AltGr + Tab. Any Shift + AltGr combos shouldn't be hindered now.
v1(Original): Consolidated and Unconsolidated

v2(Revised): Consolidated and Unconsolidated

v3(DOSBox Friendly): Consolidated and Unconsolidated

Above layouts with dedicated Escape key

Summary:

  • CAPS Lock is AltGr + Tab.
  • AltGr then Hold Right Shift with 1, 2, or 3 could be Print Screen, Scroll Lock, and Pause/Break. 
  • Hard reset is Menu + Power + L1 shoulder. Use R1 instead for hard shutdown. Forced restart is Menu + Power.
  • Kill tasks manager is Spacebar + Power(or hold Menu for five seconds). 
  • Menu could be moved to AltGr + Spacebar. Escape could then be a primary key in it’s place. 
  • In Wifi-only Pyra’s, 4G toggle is USB On/Off with HDMI-Out it’s shifted value. 
  • Key backlight toggle has four settings: off, low, medium, and high. Lid logo notifications could be switched similarly.
  • Context Menu may be at AltGr + Spacebar.

Why not use AltGr and Space for anything?

It's so easy to access with only one finger.

I would maybe put Compose there.

Much better than any other combination in my opinion.
 
It is only a software modifier in the sense that a driver handles it. No userspace application sees the fn key as a modifier.
Fair point. I think I got distracted there.
Then for our purposes the Pandora's Fn key is a hardware modifier and for the Pyra it absolutely must be the same regardless of B-Zar's objections. Like ptitSeb says, we can't call it AltGr, have it spit out the "right alt" + "1" scan codes, and expect software to realize we mean F1.
On the Pyra it should not be the same, since we want to use the shoulder buttons in games, which means that if we have Fn/AltGr/Meta/Sym on a shoulder button, then the corresponding key events should be observable.

But you're right that we have to make sure that e.g. Fn/AltGr/Meta/Sym + 1 produces a real F1 keycode.

I would call the Fn/AltGr/Meta/Sym modifier "Meta".

Alternate Graphics is a good name if it produces symbols liike []{}, but not really for F1-F12. Also keyboards rarely have 2 Alt keys and 2 AltGr keys, so it could be confusing. And finally I don't like CamelCase and I think 5 letters is a bit long.

"Meta" is a Greek prefix, it has a long history as a modifier key (and even a standard symbol: ◆), and it is neutral about its effect: it does not imply "function keys" nor "symbols" (printable characters), so it can be both.

For reference, here's my current proposal:

http://www.keyboard-layout-editor.com/#/layouts/f9f3508ae2ea1ed6de939d0100173675
 
  • Like
Reactions: szr
So, besides Grench and comradekingu who certainly have interesting ideas (and contributed much to the 'mainstream' proposals), what are the current 'mainstream' proposals?

There are Saber's proposals:

Pyra Keyboard Layouts(Updated March 30th 2015):

Optionally, map Escape onto the Menu button then assign Menu to AltGr + q.


 

And here's my compromise proposal:

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

Any others? (that take into account ED's first post in this thread; of course there are many other proposals from earlier keyboard threads)

Could we perhaps discuss now the remaining differences between the current 'compromise' / 'mainstream' / 'final' proposals?
 
Last edited by a moderator:
@ comradekingu: Correct me if I'm wrong, but you seem to be implying that the Pyra is aimed to be a device the average user should be able to just pick up and use without getting confused?


If that is what you are saying, then I am somewhat perplexed. In the reality I live in, both the Pandora and the Pyra are devices *not* aimed at the average user and a notable learning curve is required in order to get familiar with the device.


I wouldn't recommend either to someone who doesn't have the savvy, patience (and enthusiasm) to figure out a layout such as Grench's through trial and error.
 
On the Pyra it should not be the same, since we want to use the shoulder buttons in games, which means that if we have Fn/AltGr/Meta/Sym on a shoulder button, then the corresponding key events should be observable
Yeah, since that post I've been calling it "magic-do-the-thing" key (and eventually just "Hardware Modifier" or "HWM" even though it isn't strictly a hardware modifier, it just acts like it most of the time). Always it outputs a "MDTT" key code (which most current things won't be watching for but anything that wants to use the shoulder buttons can) but it also outputs the correct corresponding key combo to "do the thing" that the key says it will do, if there is a key combo. So if someone hits your "Meta"+"1", there's a "Meta" and an "F1" inserted into the event queue and SDL or whatever can pick up on either or both of those. The "1" is lost but I don't think that's a big deal, that's getting into tight corner cases where the developer can find alternative ways around it if it's really important.SDL even has a keycode we can repurpose: GUI, also known as "Windows", "Apple", or, conveniently, "Meta".
 
Any others? (that take into account ED's first post in this thread; of course there are many other proposals from earlier keyboard threads)
Do we consider the gaming buttons to be in the scope of this thread here? If so, then there's Parentheses format for button labels (please don't discuss it here, do it over in the dedicated thread).
 
Last edited by a moderator:
So, besides Grench and comradekingu who certainly have interesting ideas (and contributed much to the 'mainstream' proposals), what are the current 'mainstream' proposals?

There are Saber's proposals:

v1(Original): Consolidated and Unconsolidated

v2(Revised): Consolidated and Unconsolidated

v3(DOSBox Friendly): Consolidated and Unconsolidated

Above layouts with dedicated Escape key

v2(Revised) Consolidated and Unconsolidated

v3(DOSBox Friendly) Consolidated and Unconsolidated

And here's my compromise proposal:

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

Any others? (that take into account ED's first post in this thread; of course there are many other proposals from earlier keyboard threads)

Could we perhaps discuss now the remaining differences between the current 'compromise' / 'mainstream' / 'final' proposals?
I also like the idea of the Super and Esc keys being present, like _wb_.

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

ible-Saber.png

I scooched a few things around as I thought felt organized (e.g. U-umlaut is now on U), but there are a few keys where I have "extra symbols", like the circle on AltGr G, the AE on AltGr Y, and the pound symbol on AltGr P. I'm not going to use those keys frequently, but if someone would prefer other symbols on those keys, they are free to change.

Things I'm not a fan of:

F11 and F12 being on backspace and enter, since it'd be nice to see those free of AltGr's. One alternative is to kill the pound symbol and head south with F11 and F12:

http://www.keyboard-layout-editor.com/#/layouts/b7e41674d06347b6eb0ebe11b9817906
 
Last edited by a moderator:
Well, the key sequences are oriented around graphical similarity for most things: {compose},{"},{e} will produce ë. ({compose},{,},{c}-> ç) these are all pressed in sequence, not at the same time, so you will not break your hand doing it :D


Btw. I am German, I type in German (yes everyday stuff as well) and all my keyboards are US layouted because it is VERY good for programming.


@slaeshjag: I use the compose key all the time! So, the compose key being crap for common things is just... like, your opinion, man.
I agree with you: Althought I am Spaniard I use US keyboard because it is more ergonomic for all tipping and even better for programming. Even if I buy a computer with an European/Spanish, I change its keyboard for a US keyboard (UK keyboard are near so bad like Spanish keyboard).

In US keyboard we have a large LEFT SHIFT key, and it is much better to reach than the small LEFT SHIFT key in European keyboards. The same for ENTER KEY: for US ENTER key you onlu need to jump 1 key, but with European ENTER key (like an inverted L shape) you need to jump 2 keys to reach ENTER and that is very painful in little finger and wrist. Simply US keyboard is more ergonomic.

I have to logical layouts: US and "US International width dead keys". When I want to code or write in  my own language (it includes á, é.... ñ, etc, and I got them with RIGHT ALT key wich acts like ALT_Gr) I use US International layout with dead keys, and when I want to code and write only in English I use US layout.
 
oskda: We cant use our AltGr key for that, since we because of the lack of keys need it to type third-level modifiers. Something that also lets the standard symbols
stay at the number row. Instead of using US international AltGr we can use US international alternative method of dead-key typing
which is ctrl+alt.

Ctrl+alt are on shoulders, and can also be on the keyboard.

The most central place to put them is in the column-row, which enables

combo-typing with 5 6 and 7. You can press select(ctrl)+start(alt)+5 to get accent aigu, retroflex on 6, and accent grave on 7

However the reason for using US keyboard goes away when you switch to two-thumb keyboard, because it doesnt matter how long the shift is.
It actually doesn't matter if you have a shift on the left side at all. This is because you would only use it after ending a sentence with
the right hand on the right side, which happens only in the cases when your sentence starts with a big letter that is found on the right side.
You would never have to reach over to the other half of the keyboard with one hand to start a sentence. But to even do that, you would need to

shift focus and movement over to the left thumb and tie that up at far left, rather than combo-type from space onto shift with the right.

Anyhow, it is more effective yet to use shoulder-shift, so the potential left shift part of the flow-chart is a de-tour.

You could argue that you would have a little more efficiency when you are placing the pyra on the desktop and you dont have access to the
shoulders, but in this case you could use all 10 fingers.

A counter argument to duplicating the shift on the right, is that since you need it on the left, and it doesnt do anyhting there, it is better
to only learn where it is once. Countering this, is convention. People are used to shift on the left from regular keyboards, thats the one
most people use.

However, that is junk science, and it only teaches bad habits and gives credit to something that is unergonomic.

TL;DR on the above means you can get the benefit of using a spanish keyboard without any loss (shift and enter key preference from ANSI to ISO). Meaning you can type ñ and ç on dedicated keys, and also you get the ^-compose-key from spanish layout.
 

@ comradekingu: Correct me if I'm wrong, but you seem to be implying that the Pyra is aimed to be a device the average user should be able to just pick up and use without getting confused?

If that is what you are saying, then I am somewhat perplexed. In the reality I live in, both the Pandora and the Pyra are devices *not* aimed at the average user and a notable learning curve is required in order to get familiar with the device.

I wouldn't recommend either to someone who doesn't have the savvy, patience (and enthusiasm) to figure out a layout such as Grench's through trial and error.
You are 100% correct. And i quoted ED in saying so. From firstpost

  • "The keyboard should be standard enough to be used by every normal user"
The reason this is so true, is because lowering the bar means more people can enjoy it. There isnt any benefit to making it complex for the fewer people who can use it then.
Just like there isnt any benefit to english people by excluding international localization and standards.

It could be that ED posted the wrong layout in his firstpost, or that he just assumes it will work. However in my trials, it fails. 
I can post the argument as to why, but as long as Saber doesnt answer, this is a repeat of the "unofficial keyboard thread"  In which anyone could post something and not answer to the questions it raised. In turn why I made my own tread.
I understand now why these keyboard treads are tedious, I've just been hanging out in my own.

Edit: From my experience in making layouts, you can rarely change things around without ruining the holistic approach of what makes a good layout good.
It takes a lot of time to balance something within the restrictions given. Design by community doesnt change that. Its not an additive process.
Balancing something doesnt happen by mere accident. If you cant arrive at something final, you will forever be changing things around.

Assuming things without trials or research fails, I have done so a lot. Discussion also helps, but artificially limiting it and not answering doesnt.
We are however done with that, done with a lot of discussion, done with a lot of polls. The layouts that are final have stopped changing many months ago.
Since we are the ones paying for the keymats, based on our interest therein, cant we just vote among the final layouts and see what proves
popular? And finally be done with keyboard layout threads.
TL;DR can we vote over the layouts and try them out? The current discussion and proposal is a variation over a theme i dont see much value in.
The proof is in the pudding at this point.
 
Last edited by a moderator:
Why not use AltGr and Space for anything?

It's so easy to access with only one finger.

I would maybe put Compose there.

Much better than any other combination in my opinion.
The problem with Compose Mode is once you are in it, how do you back out of it without performing a sequence? It's not like single-use Menu or Tab which are done with when you hit another key. Will software let you type AltGr + Spacebar again to cancel? I'm sort of reluctant to put anything on AltGr + Spacebar in case the user wants to press Spacebar while in AltGr mode.

BTW, there's more I want to do with the layouts, but I think I'm almost nearly finished.  :)
 
Last edited by a moderator:
This post is just me saying I always listen to everyone's criticisms and will do what I can to include their ideas.   
 
For those who want an Escape key as primary(although for me AltGr + q is acceptable), with this particular layout the way I'd do it is move Escape to where Menu is, then move Menu to under AltGr + Spacebar. I press Escape more often then I need the Start Menu, but as said where I had put Escape is fine too.
I like that idea, ESCAPE in the place of MENU, very much. I think Escape is a very important key for a Linux computer (that is Pyra) and even for emulating other computers.

I hope at least we have a very good keyboard customization utility in Pyra :)
 
I like that idea, ESCAPE in the place of MENU, very much. I think Escape is a very important key for a Linux computer (that is Pyra) and even for emulating other computers.
ESC isn't missing in any other layouts designs. Question is if it's necessary as a primary key. I personally never had any issue of the ESC key being shared with Q on the Pandora(ie FN+Q = ESC).

I could care less about a menu button, but I personally don't like that location for the ESC key.
 
I think that DEAD KEY DIACRITICS (like Meta+' for the acute accent) is better than having a key/LABEL with ö, ü, ä, etc. Even I think people watching those LABELS on the keyboard may be frightened thinking it is a local product only for one language.

I think no one gets frightened watching ´ ¨ like 2nd symbols (the same way we watch [ ] { } ^ etc), but watching ö, ü, ä, etc, seems like a local product, not a neutral/international product for all latin alphabets.

I think a neutral way to include all or most of the latin alphabets with dead key diacritics is the better way, because it is neutral and capable for near all latin alphabets language. And if needed, we can have optional language layouts via software, where one can change the layout and have for example dedicated ö, ü, ä without dead key use.

PD: I am Spaniard and we use á é í ó ú really a lot of because that accent indicates the pitch accent in a fixed rules, and all those are entered via dead key. If I see a keyboard with ñ and ç I know it is Spanish, but if it a keyboard instead have no local symbols but optional diacritics ~ ¨ etc, I see it like neutral.

 
 
Last edited by a moderator:
You dont need the symbols, you just need the keys they are on. If they are available, each language can use them like you would if you switched
to spanish layout on your US keyboard. That works. And it means we dont have to see foreign stuff on the keyboard. Which was one
of ED's requests if i read it correctly.
 

I like that idea, ESCAPE in the place of MENU, very much. I think Escape is a very important key for a Linux computer (that is Pyra) and even for emulating other computers.
ESC isn't missing in any other layouts designs. Question is if it's necessary as a primary key. I personally never had any issue of the ESC key being shared with Q on the Pandora(ie FN+Q = ESC).

I could care less about a menu button, but I personally don't like that location for the ESC key.
For many people this was a veto-thing. Also the most requested dedicated key along with tab.

Also the pandora couldnt trigger escape with shoulders.

Edit: Seems my layout is now in full accordance with http://boards.openpandora.org/topic/16868-the-big-pyra-keyboard-poll//URL]

Whereas layouts that dont include a fuller alphabet _arent._

Really dont see what there is to gain from excluding _over half_, when everyone voting would be covered by the inclusion.
 
Last edited by a moderator:
Back
Top