It's the keyboard layout.

[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?

 

[_wb_]

My issue with Grench's layout is not that it uses Shift+Fn combinations. That makes perfect sense, and everyone does that. Even the Pandora does it: consider Shift F1-F12.


My issue is that it does not have dedicated primary keys for comma and period. I think those symbols deserve to be on dedicated primary keys, just like on the Pandora.


Also a minor issue might be that if you print four labels on one small key, legibility may be a problem.

 

[comradekingu]

What part of using Fn, and especially shift+Fn, makes any sense at all...? Who does that?

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

WizardStan: "Follow US keyboard standards."         "; is Fn+G"   Pick _one_!

Not being able to think of a reason why it will break, is not a good reason to go ahead and do it. It took me about 20 seconds of research to find this:

https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts#User_interface_navigation_.28widgets_and_controls.29

If shift+(fn)+F is a modifier, you cant type shift+f-keys at all. Or is that when you have to remember the difference between the two shifts? Give me a break.

It seems people equate "its hard to do because of a lack of keys" with "i can just fail at this, and do whatever i want, even if its not what people want".

Not only does non-standard things change standard conventions, it also breaks other standard functionality as a result. That doesnt get any better when the same is done at a software level. Which happens, and will continue to happen in the future. We _need_ to stay keyboard compatible.

, ;   being regular and shift and   . :   being regular and shift is standard euro, there is nothing wrong with that, and it makes just as much sense.

The key is 7x3mm, 3 prints horizontally is the sane maximum, putting things atop each-other only works if you use the layout-editor to make extra space on the keys.