It's the keyboard layout.

[_wb_]

How well does Swype work with non English languages? I am forever impressed with how well it works for English and wonder if it is as good with other languages. I am not suggesting we should use touch input for the Pyra more thinking if Swype can guess the right word with squiggles on the screen, it should be possible for software on the Pandora to work out what accents to use (based on spelling and context).

Typically English is the best language for any software, since typically it is the first language that software supports.

Working out accents based on some kind of auto-correct / guess mechanism is probably not a good idea. One of the main advantages of a real, physical keyboard is that it is so much more accurate than a touch keyboard: if you make a typo, it's you who made the typo, not some inaccuracy in the touch detection hardware or some kind of incorrect guess by some kind of auto-correct mechanism.

Also it is not that easy. E.g. in French, both "a" (has) and "à" (in/to/at) are very common words. So working out the accent is not trivial: at the very least the software would need to understand French grammar. It's even worse in a language like Dutch, where accents can be used for emphasis. E.g. "háár haar" means "her hair" while "haar háár" means "her hair". Another use of accents in Dutch is for disambiguation: "voorkomen" is usually spelled without any accent, but it can mean both "prevent" ("voorkómen") and "occur" ("vóórkomen"), and depending on the context, it can be impossible to know which one is meant if you don't write the accent. Same with "één" (one) and "een" (an) - typically both are grammatically possible, and it depends entirely on the writer's intention which one is meant.

So in summary: With the current state of the art in artificial intelligence, there is no way that software can automatically solve this problem. If software can work out the accents, then it can basically also pass a Turing test.

 

[codifies]

Its a well known problem with at least one commercial solution reaching less than 1% error rate easily correctable on the fly, there are a buch of papers on this problem as it lends itself to stochastic analaysis

 

[Saber]

Added a "what if" centered spacebar version of my main v2 proposal layout to my sig.  

v3 features:

• The , and . keys are over on the right, on the same row.
• Two keyboard AltGr's(rather than just one tucked at the edge).
• Spacebar where it's normally located so both thumbs can press it.

Although this new-ish layout is posted months before line production will really begin, it has a snowball's chance of even happening at this point. For the record only. Maybe some more insights will sprout from it.   

 

[codifies]

While the Pandora keyboard wasn't as bad as the zx spectrums dead sea creatures, I do hope that the keys have even less give... Its one thing for a key to have travel but to be soft and squishy when the travel stops just isn't nice!

 

[rygD]

While the Pandora keyboard wasn't as bad as the zx spectrums dead sea creatures, I do hope that the keys have even less give... Its one thing for a key to have travel but to be soft and squishy when the travel stops just isn't nice!

I think those were some of the issues that were trying to be corrected.  Did anyone who was physically close to a Pyra protype with keyboard piece test it out?  I understand that there probably weren't any key caps so it would be hard to get an idea of overall feel, but you should have been able to tell if some things might be better.  I probably already read someones thoughts on this and forgot.

 

[Christoph.Krn]

Reading Finding an Optimal Keyboard Layout for Swype, I just happened to stumble upon this:

Dodona

(Just to prevent misinterpretation, let me note that I'm _NOT_ suggesting to use something other than QWERTY at the core of the Pyra keyboard.)

 

[lennaick]

 Accented  charcters miss me on the pandora, it's annoying for me to type without é è à ç ï ù œ and … « »

Using AltGr+<deadkey>  <key> it's possible to print nearly everything (like this keyboard that print all latin enropean char and more : http://bepo.fr/wiki/Touches_mortes )

 

[blip]

I use French bépo layout (maybe as Lennaick) and I'm a touch-typist so I'd rather use all of my fingers with an external mechanical keyboard if I need to do some long typing. IMHO the integrated keyboard should be here for some punctual use because the thumb typing, the size restriction and the shape of keys can't never beat a plain external board for hard working.

So you must stick with the US-QWERTY (because it's the legacy for Linux Kernel, Syst Req Keys and plenty of softs like most of those depending on SDL) and put an Fn key to map all the keycodes in the keyboard part (perhaps with the ISO 105th key).

Everyone who wants another layout than US-QWERTY should be able to use XKB and a gamepad key configurator or a special Pyra software regrouping both.

For the labelling, stay in us-qwerty too. With the characters for virtual keys accessible through Fn. Because of backlight, stickers aren't very suitable but you still can provide blank transparent keycaps as spare part for modders.

Tl;dr : Stay legacy as close as possible from keycodes labels and Linux Kernel. IMHO it's the most elegant way to do this.

 

[comradekingu]

What does FN+symbols on the typewriter part have to do with any US standard?

The baby was thrown out even before you drew a bath.

 

[codifies]

I think he probably means based on US layout ... I recon there would probably be enough light spillover to read labels and keep the keymap from getting redonculously crowded, either labels or a removable template around the keys..

 

[comradekingu]

Then you have to consider what that actually is. You end up having to put some of it on keys that dont exist.

And the reason why US layout can put symbols on keys that otherwise dont have them, is because their alphabet is shorter.

So which one is it, print symbols on typewriter keys that dont have symbols in US layout, or something that is _closer_ to US layout.

What was described was extremely good at excluding everyone else, but doesnt even work for accomodating who is left.

 

[codifies]

With a set of labels or interchangeable template around the keys *customised* to *one* language you leave no one out and also don't inconvenience *everyone* trying to be all things to all people

 

[comradekingu]

Trying to be all things to all people isn't actually how things fail. They fail by not being a regular keyboard to anyone.

Those "other people" dont expect symbols on the letterkeys either. Its non-standard to begin with, then made worse by trying to "accomodate", made worse by doing that for all different regions.

Being a good keyboard to all people is very much possible, at-least to the ability the limitation of keys gives.

 

[codifies]

I believe trying to be all things to all tasks AND all languages with a limited set of keys is a big mistake that will always be a poor compromise, this is why I suggested interchangeable templates that clip onto the keyboards with the extra symbols for different key maps this way you could have one for French one for English , fancy a custom layout specifically for DOSbox ? Or coding? No problem! Oh I suppose you could also have a German layout too ;-)

 

[comradekingu]

The opposite is being no things to any people, listen to your argument before you make it. Belief does not a layout make.


As for interchangeable things, yes, I fully agree.


But if you try to make it the same to all people, as in the common denominator being the number of typewriter keys, and position (,between ANSI and ISO), you only need to exchange part of the right half of the keyboard.

 

[codifies]

Favoring one half of the keyboard for a keyboard used by two thumbs only is not a great idea...

 

[comradekingu]

Thats what im not doing. I consider a keyboard to be a keyboard. My line of reasoning goes back over 100 years.


Excluding half the userbase to make the default less of a standard keyboard for anglo users is a mistake.

 

[blip]

Just to be clear : I don't talk about layout preferences and needs for characters (I'm a partisan of making your own layout to suit your exact needs) but about the level under that, the keycodes input by the keyboard itself. If the keycodes are directly input without any additional software, it's best for compatibility and anybody can make a setxkbmap command to change the default qwerty to its favourite layout.

An hard coded Fn layer allows to input keycodes instead of a soft coded layers in an xkb file which be unacknowledged by the kernel.  Us-qwerty is just the legacy layout of the Linux Kernel : The one he understands without xkb config file so IMHO it's important to keep it because of Magic Syst Req keys. This Fn layout can still be rearranged if the keyboard micro-controler is reprogrammable (or maybe by the Boot file used in ARM arch instead of BIOS, I don't know well the possibilities of this booting process) so there is no problem for customisations. I don't know what issues occur with Pandora's Fn key but if it's cleanly done, there will be none.

In addition to Syst Req keys, some (bad programmed) games use keycodes directly instead of characters input and the majority doesn't allows to configure mapping, there are still plenty of FOSS games in this case (and if one day Pyra provide an x86 CPU board, it will add the proprietary ones). Any game or program using keycodes without taking care about layout will correctly run as is without wrong layout issues and the us-qwerty labelling will match their prompted keybinding help. That's a very common problem for those who use a dvorak-based layout.

So, that's why I think the keyboard need an hard-coded Fn key independent of the OS and why the us-qwerty should be the default label on keyboard.


Concerning interchangeable keyboard clipped on the Pyra (like a mix between the Typematrix skins and spare keyboard part of a laptop) that's a pleasant idea but the actual design isn't made for that and all those optional pieces will increase the price. And they still will be people unsatisfied because one or another layout labelling isn't available (colemak, Neo, belgian azerty, swiss qwertz, korean, uk-qwerty, customised layouts, etc. )
To me, a better solution is relegendable keycaps as it exists for Cherry MX keyboards (used mostly on Point of sale keyboards like Tipro do) because it will please anybody, but again this might increase the final price.

 

[comradekingu]

Why and how is sysRq important?


The keyboard controller isnt hardcoded, nor hardware-interrupt.


Dvorak is already out if you want to do doublewide space.


Given 104 keys, US layout would work without hassle.


What games are troublesome without A-Z and basic first level punctuation? Isnt it easier to just put a layer in between them taking over the framebuffer and input?


If they are FOSS games, fixing broken functionality where its broken sounds like a better idea.


Keycaps idea is novel, but couldnt be done. I have researched that extensivly, and you basically need a wider keyboard to do it well.


Additional keymats dont increase the price of the basic product, since they are optional. Selling to more people brings the price down.

 

[WizardStan]

some (bad programmed) games use keycodes directly instead of characters input

That's actually necessary. There's no character code for ctrl, alt, or shift, nor the arrow and F1-12 keys; backspace, enter, insert, delete, home, end, PgUp and PgDn are all just "ctrl"+"something" characters, so there's a lot of potential for programatic confusion if you're using characters instead of key codes.Further, if using the character mechanism there's no way to know when a key has been pressed vs released, you just get a stream of characters from the OS (with the time between each character being kernel configuarable and not ever fast enough for real-time reactions) and kind of have to guess where the key press starts and ends, and you'll be wrong if you need it to be millisecond accurate.

Finally, you say "some" games when really it's "pretty much every PC game written since the dawn of time". Like, obviously not text input games, at least not all of them.

Regarding not being able to change the controls, I agree, that's just laziness.