It's the keyboard layout.

[Saber]

So why isnt it called (Alt)? Are these all technical markings, or how you envision it being on the device?

That looks a lot like the L2 shoulder, if you want to follow the playstation-paradgimn of L1 L2 R1 R2

Do you happen to know why the right shift was on the left shoulder on the two-shoulders pandora?

If your concern is only software-compatibility, id like to know when that matters. Also id like to disagree,

most of the software library for the pandora is static compiled, without source-code available. And when it is,

it isnt automated.

In the drawings, where the screen is, I equate Start with Left Alt. As you surmise, it's how I envision them on the Pyra.

I'd fathom a guess and say it was an aberrant design choice nothing more. They could have placed Right Shift on R1 and Right Control on L1 but they decided the other way. Maybe Craig flipped a coin?

I don't speak for everyone, but besides software compatibility for legacy sake, I thought it best to minimize the relearning curve for controls since the established Pandora user base will also migrate over to the new machine. I think the assignments for the action buttons were already well thought out: ABXY for Home, End, PageDn, and PageUp. 

 

[comradekingu]

The current, quite small, pandora userbase, have pandoras that they can use to play pandora games. Please name the ones you think arent going to be ported, that are important enough to change the layout in a detrimental way over.

As for learning curve, what do you think the current pandora users have used the most. Pandora or real keyboard?

------------------------------------------------------------------------------------------

Have you shown the keyboard to a normal non-techncical user, what did they say, did it work?

-

Why is it balanced between text input, and coding? What efforts have you made to facilitate this.

Why have you chosen to omit the keys all normal keyboards have, in favour of left shift, left ctrl and caps lock? (only the english alphabet fits)

Can you take me through the process of how left shift, ctrl, and caps lock do anything meaningful?

What have you done to support the english and German as best as possible, in relation to every change made different to their respective local layouts?

What about french?

- I don't want to hear about how the French (or the Slavics) are misrepresented

Why do you think its ok to call a key AltGr when it doesnt do what AltGr does? (ED may be the correct person to answer this)

Why are two of the most used keys , and . in the least central positions?

What does Br+ and Br- do?  Do you expect people to guess that its brightness if they havent ever seen a pyra before?

Why continue BXYA when its now nearing extinction? Are you aware that the people who made it dropped it later?

Why are the most typed sequences not closer together. Are you aware that this is one of the most important factors in making a keyboard efficient? (Dot isnt close to enter, comma isnt close to space. Enter isnt close to dot)

Is there a logic as to where the symbol is printed on the key, and what modifier it is. Is there a further connection to where those modifiers are to be found?

Do you intend to put the symbols above eachother on a 3mmx7mm key?

Why dont you have any combos going from bottom of column-row onto 5 6 and 7?

Why do you call AltGr+space to bring up the menu "ideal", when there is a button in your layout called menu? Did i understand that correctly?

Why does + and -  mean insert and delete? Isnt > and x better?  Is it not a problem that + and - is also on the keyboard?

Why do you have so many layouts? What is the point of each of them, (good and bad)?

Why do they keep changing?

Why is F11 behind F10?

Which button does third level modifier on the key that says , < ;   and . >

What happens when you press the button that says USB/4G?

What happens when you sell a keymat that says 4G with a device that doesnt have 4G? (all devices may not have this)

What are your thoughts on :

Select being first on game-controllers, shouldnt it be first on the column row?

Visual clutter? Would you buy a keyboard that had symbols all over the letters?

Printing the number keys in the f-key modifier colour (except for F11 and F12) to save on visual screen estate?

Will be updated with answers, and more questions.

 

[sabrecheeky]

Please, please, please can we not use the right nub for mouse buttons this time? The constant frustration of the wrong thing being selected is my main bugbear with my Pandora. I know there are solutions, but they mess up game controls.

Honestly, when I showed my pandora to friends, they could not believe how cumbersome it was to use. It really put them off. Just swap PageUp/PageDwn/Home/End onto the nub, and put the mouse buttons on ABXY. Or, better still, use they new buttons. Anything!

Don't make me beg!

 

[comradekingu]

Well the new nubs click, so thats something. You cant actually mark the nubs with anything that signifies pageUp/Dn/Home/End, so thats a bit of a problem.

Describe the whole thing visually please.

 

[WizardStan]

Please, please, please can we not use the right nub for mouse buttons this time?

I'm pretty sure no layout has proposed that. Seems like they've all got one nub for movement and the other for scrolling.

Don't make me beg!

You already are. And for something that isn't even an issue. Pfft

 

[WizardStan]

It occurs to me that we are lacking a lot of information in the technical design of the Pyra. The keyboard matrix, the behaviour of the game keys and what all is on a GPIO, whether any of them are on interrupt lines or attached to the PMIC like the Pandora's menu button, probably a few other things I'm not thinking of right now.

Can't come up with a final design suggestion without knowing these things.

 

[oskda]

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.

Out of curiosity,  why bother switching between the two?   I have mine set to US International full time and have never had any reason to switch it back to the regular version. (and I usually only actually use accented characters during my French lessons)

- Neelix

Really I use mostly US International, even when writting English, but I like to have the pure US for some times because in US International layout I have dead keys, and in that way when I want to write only one ´ symbol I must press that key twice (or press ot and SPACE). I could use the other variation of US Internatinal with AltGR and no dead keys, but in Spanish keyboard we use dead keys so for me is a bit more ease.

 

[oskda]

My proposal (http://www.keyboard-layout-editor.com/#/layouts/f9f3508ae2ea1ed6de939d0100173675) does not have explicit labels for dead diacritics (to keep things simple), but it does have dead diacritics by default.

It has a dedicated key for quote / double quote ( ' / " ), and this key does not have any Meta labels, since it is meant to be a dead acute accent (áéíóú) and umlaut (äëïöü) when used with Meta. My backtick and tilde (` ~) are on Meta positions, and the idea is that they can be used as dead grave accent (àèìòù) and dead tilde (ñõ) when used with Meta+Shift. Also Meta+comma is available for cedilla or ogonek (çşąęįų).

Any Latin-based letter with diacritics can be entered in just two thumb-presses in this way (since Meta and Shift are available as shoulder buttons, so no thumb travel is needed for those). Or in three thumb-presses if you use the Compose key method (e.g. Compose " U for Ü, Compose A E for Æ).

For comparison, on the Pandora the situation was much worse. The Pandora does not have Fn on a shoulder button, and it does not have dead diacritics. So to type é on the Pandora, you need at least four thumb presses: Shift-Enter (L1+Enter) for Compose, then Fn, then A (for '), then E.

Really I like your proposal very much.

 

[ible]

I also generally like less clutter, and would prefer not filling up the board with the AltGr symbols if possible.

Here's my take on _wb_'s, which localizes the math symbols quite well (<*-=+/> are all very close):

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

But it seems like ED wants two keyboard shifts, which makes the AltGr space a little more cramped.  This is my "mathematical" take on Saber's layout, organized for some coding:

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

There are a few keys left un-AltGr'd, in case someone has uses for them.

Spoiler

old versions of my taken on Saber's layout:

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

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

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

It is my understanding that on international keyboard settings, keys like ', ^, and ` are "dead keys", so there is no need to have a compose key, you just hit those and then the next key you want to modify.  Just change your layout from US to French or whatever.

 

[_wb_]

Wb: Well you are still without mediabuttons when the lid is open. Its conventient to have that.

In http://en.wikipedia....nch_orthography

 

[_wb_]

But it seems like ED wants two keyboard shifts

Not really. He just said that one of the things he likes about Saber's proposal is that it "Even has two shift keys (useful for persons who don't use the shoulder buttons when typing, like myself ".

So this is not a requirement, just a "nice extra". But it is a "nice extra" with a number of disadvantages:

• One less key available for other things -- and not just any key, a key in a very nice position.
• Two keyboard shifts and one shoulder shift means THREE shifts in total, which means they can't all be distinguished from one another. This is a bigger problem than you might think. For example, if you have two keys that are both LeftShift, then it can happen that you press down one of them, then the other, then you release one of them while still holding the other. Now you are still holding down 'Shift' (one Shift that is), but most likely, the software will think that you're not, because all it has seen is [LShift down] [LShift down] [LShift up]. This kind of stuff could also break software that simply does not expect weird sequences like that.

Also it is not really particularly useful for the use case ED describes. If you don't use the shoulder buttons as modifiers (a big efficiency loss if you ask me, and I wonder if we should really optimize for this use case), then you would need to have all modifiers reachable with both thumbs. Also Fn/AltGr/Meta. Unless you make those modifier keys sticky (the ones on the keyboard only, not the shoulders!). That's why the Pandora gets away with just one Fn key: it's a sticky key! That's why it would have been better if the keyboard Shift (LeftShift) on the Pandora would have been sticky by default as well.

Sticky shift for thumb typing (without shoulder buttons) is not really an exotic idea. All smartphones and tablets do this too. And a quick double tap on Shift becomes CapsLock (or ShiftLock, I have no strong preference in that debate). It makes sense. Way more sense than sacrificing a key to optimize for a use case that is inefficient in the first place.

(Of course sticky or not would be something you can configure in software, I'm not saying it absolutely has to be like that by default, but at least it should be something that is easy to change for non-technical users)

 

[Neelix]

Oh, I see, so DeadKey E would e.g. produce é, DeadKey E E would give è, DeadKey E E E would give ê, DeadKey E E E E gives ë, and so on for ě ę ē ė € and so on?


This is not usually what is meant with dead key diacritics. Usually it means that you have specific keys for e.g. acute accent, so that if you press that key, nothing happens, but when you press the next letters, it gets accented with that particular diacritic (e.g. ẃéŕýúíóṕáśǵḱĺźćńḿ). So you would have multiple dead diacritics.

True, but oddly enough I would say that the method you inferred from Grench's error does have some merit to it.   I currently use a greasemonkey script with Duolingo, which detects what language I'm supposed to be typing in (in the context of the duolingo lessons) and allows me to cycle though the possible accents for a letter by pressing alt.   So if I need to type an è (When I'm supposed to be typing in French) I can press e followed by alt.  If I need to type é I press alt twice.  I find it actually works pretty well if I'm doing the lesson on the Pandora keyboard.

For DosBox, Comma(,) MUST reside on the same symbol pair as (<). Period (.) MUST reside on the same symbol pair as (>).

I don't really get what all this DosBox fuzz is about. Isn't this all just a matter of making sure that the DosBox emulator translates Pyra inputs to IBM-PC inputs in a way that is as correct and complete as possible? We can't have a standard 104-key keyboard, so that mapping will always be a bit tricky. But I don't really see the problem. If the emulator has to fake a Shift+comma in its emulated IBM-PC keyboard whenever you input a < on the Pyra, then that's what the emulator has to do, but why would that imply anything about how you physically input a < on the Pyra?

The issue is with how the keyboard mapping works within dosbox.    Dosbox doesn't let you map ',' and '<' individually,  it lets you map the ',' key and the shift key and assumes  '<' to be shift + ','.  (and so on for all shifted characters on the US standard keyboard layout)

This faulty assumption isn't just specific to Dosbox either.

There was a similar issue in Oolite, (for example) which ptitseb had to specifically modify the code to fix.  

- Neelix

 

[WizardStan]

I assume that the software issues can be sorted out to make sure that the overlay menu always shows, regardless of which application you're running.

It can. I demoed a new menu overlay for the Pandora way way back that worked with everything. There's multiple frame buffer layers, even when something is writing directly to the screen the OS still has control of the topmost layer and you can draw an overlay menu onto that.edit: and just to be clear, the OMAP5 also has multiple graphic layers, so it can definitely be done. Like my original Pandora overlay demo, however, I wonder if it'll actually get done.

 

[ible]

But it seems like ED wants two keyboard shifts

Not really. He just said that one of the things he likes about Saber's proposal is that it "Even has two shift keys (useful for persons who don't use the shoulder buttons when typing, like myself ".

So this is not a requirement, just a "nice extra". But it is a "nice extra" with a number of disadvantages:

• One less key available for other things -- and not just any key, a key in a very nice position.
• Two keyboard shifts and one shoulder shift means THREE shifts in total, which means they can't all be distinguished from one another. This is a bigger problem than you might think. For example, if you have two keys that are both LeftShift, then it can happen that you press down one of them, then the other, then you release one of them while still holding the other. Now you are still holding down 'Shift' (one Shift that is), but most likely, the software will think that you're not, because all it has seen is [LShift down] [LShift down] [LShift up]. This kind of stuff could also break software that simply does not expect weird sequences like that.

I agree 100% with your concerns.  But if ED doesn't want two keyboard shifts, why did he single out Saber's layout as the "nigh perfect" one?  Many other (non-Grench-styled) keyboard layouts have every other qualification that ED said:

Mostly Standard QWERTY-Keyboard, including the Shift-Keys on the numbers

Tab as a single key ä, ö and ü (German) as well as ' and ` (French) included

Almost all normal characters are existant

Even has two shift keys (useful for persons who don't use the shoulder buttons when typing, like myself

For most of our layouts we allow for umlauts to hide on AltGr+(That key).

 

[_wb_]

For DosBox, Comma(,) MUST reside on the same symbol pair as (<). Period (.) MUST reside on the same symbol pair as (>).

I don't really get what all this DosBox fuzz is about. Isn't this all just a matter of making sure that the DosBox emulator translates Pyra inputs to IBM-PC inputs in a way that is as correct and complete as possible? We can't have a standard 104-key keyboard, so that mapping will always be a bit tricky. But I don't really see the problem. If the emulator has to fake a Shift+comma in its emulated IBM-PC keyboard whenever you input a < on the Pyra, then that's what the emulator has to do, but why would that imply anything about how you physically input a < on the Pyra?

The issue is with how the keyboard mapping works within dosbox.    Dosbox doesn't let you map ',' and '<' individually,  it lets you map the ',' key and the shift key and assumes  '<' to be shift + ','.  (and so on for all shifted characters on the US standard keyboard layout)

OK. Then DosBox makes faulty assumptions and it should be fixed. This issue probably affects not just Pandora and Pyra but any other keyboard that breaks its assumptions (e.g. a standard German keyboard has ; at shift + ',' and : at shift + '.'). Broken software should be fixed. DosBox is FOSS so it shouldn't be too hard to send a fix upstream. We shouldn't design new hardware to work around broken software.

I mean, it is hard enough to design a good handheld keyboard with all the physical constraints that we have. We can't take into account arbitrary software limitations coming from existing emulators that make too many assumptions about similarities between the hardware it is emulating and the hardware it is running on. Also I don't see why DOS should be more important than, say, Commodore 64 or Amiga. We're trying to build a general-purpose handheld computer here, so it should be designed with general-purpose in mind.

I agree 100% with your concerns. But if ED doesn't want two keyboard shifts, why did he single out Saber's layout as the "nigh perfect" one? Many other (non-Grench-styled) keyboard layouts have every other qualification that ED said:

I'm not going to try to come up with hypothetical explanations of ED choice, but I do think that it is very well possible that he didn't read through all of the existing keyboard threads and all of the arguments presented in them, so his initial choice in the first post of this thread may have been not perfectly informed and thought-through.


That and nearly any other layout did not have explicit labels for Ä Ö Ü ß, which I suppose he kind of likes, with his home country in mind.

 

[TrashyMG]

The version of DOSBOX on the  Debian Jessie armhf repository(IE Pyra OS) is optimized poorly and has garbage performance, we will need to roll our own version anyway. We can get a modified a keymap for it.

 

[Eight Bit]

Oh wow _wb_!!!! Yeah! I want a C=, Run Stop and Restore key!

 

[comradekingu]

Im pretty sure ED just discarded everything that didnt have doublespace. Thats why i added it in later. There actually is some truth to how you distinquish space as a wide key better.

Whether it holds up to the reasons for not doing it is irrelevant if ED wants to put his foot down.

Would be nice to have confirmed, or at least, to the extent possible, all information upfront.

 

[ible]

Both _wb_ and I have made keymats for double-wide spaces since the "Ask ED questions" post...

 

[WizardStan]

We shouldn't design new hardware to work around broken software.

I like Grench's design, not because of DosBox and QEMU compatibility, but because it follows a standard US English keyboard as closely as can manage in the small space.Standard keyboard, ":" is "shift"+";". Pyra keyboard, since ";" is "Fn"+"G", so by the same convention ":" would be "shift"+"Fn"+"G". After I started thinking about it I realized how well it actually mapped in my brain.

And I cannot really think of any good reason NOT to use "shift"+"fn" combos. There's a potential technical issue where some keys may not work, depending on the keyboard matrix, but that'll effect between 2 keys and 2 rows, leaving us at least 2 rows to play with.

"But ED said..." EvilDragon said what he'd like, not what will be. It's common practice on this board to try to convince him to change his mind long after the decision has already been finalized, I don't see any reason not to make suggestions this early in the process that may go against what he said he'd like in the hopes that he didn't think of that idea. I didn't think of it, and when I saw it and did start thinking about it I realized it was a pretty good move in what I feel is the right direction. Maybe ED would feel the same.

"Too much clutter..." except that they're symbols in places we're mostly already familiar with. I'd argue that putting ";" and ":" as part of a four-symbol key is more intuitive and less mentally taxing than having ";" and ":" be on two different three-symbol keys. But that's just me and merely serves to demonstrate that arguments of complexity are poor.

With all this in mind, can anyone come up with a valid reason why four-symbol keys (regular, shift, fn, and shift+fn) absolutely cannot work and should be taken off the table now?