It's the keyboard layout.

[ShleeDragon]

Could somebody turn that into the webapp keyboard design maker?

 

[bzar]

Could somebody turn that into the webapp keyboard design maker?

http://boards.openpandora.org/topic/17881-its-the-keyboard-layout/page-3#entry376585/URL]

 

[bubblebee]

Changing keyboard layout too much from standard is not very advisable. Look at the major concerns Lenovo created 1 iteration ago. Ideally you should optimise for minimal mental adjustment to go from a PC to Pyra. back and forth.

I'd stick to something close to US International (compose keys), so that Vi / Emacs / ... users are not screwed up. Keep Esc, Super, Ctrl, Alt, /, []... as close to where they are as possible, and also in dedicated keys.

It's gonna be tough to keep everyone happy. I'm Scandinavian, so US International with compose is suboptimal, but it's good enough. For major optimizations, remapping is gonna be needed anyway.

+1

 

[codifies]

Okay I think there may be a way to make everyone happy!


Have a US + programming symbols keymap, however do everything else - even euro! Etc with a stencil that snugly fits over the keys


It might be possible to keep this in place even without any kind of clip, yet without fouling the keys...


On this stencil would be any special symbols needed only for a particular language


There could be for example a German one that would have a bunch of German language characters on it (the user would have to select with a utility the appropriate layout)


The German user could then using a convenient key combination (that would also clash with the other languages) could then type the special characters...


If made from a cheap enough a cosmopolitan user could pick up a Euro pack of stencils maybe for only a few Euros!


Now all we need is a forum thread for each language to come up with the stencil design... And more buckets of popcorn...

 

[_wb_]

I adapted my proposal, looking at Saber's proposal and ED's remarks about it. This is the resulting compromise:

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

Is there any reason for not having AltGr and shift in the same side?

I would greatly appreciate having them one above the other (shift above AltGr) to be able to:

1. Map additional keys to AltGr+shift+key

2. Use always the same thumb for the modifier.

Rationale:

The first one is to enable the user to use xmodmap to reconfigure the keyboard for the non-supported languages -- in my case, for Spanish, I would like to map 'ñ' to AltGr+N (and 'Ñ' to AltGr+shift+n) and also move some symbols out of a key to have a dedicated dead key "acute accent" (´). The moved symbols could be relocated to AltGr+Shift+some-key.

The second one is to (IMHO) fix a shortcoming on the Pandora's keyboard . The Pandora has Fn and shift in opposite sides, and it is annoying when you aren't sure of the modifier to use to enter a specific symbol --as in: "was left thumb + 7 or right thumb + 7?" you try one, fail (Murphy?), and have to reposition both hands to try the other combination.

In my proposal, you could swap the Shift key and the ' " key.

On the Pandora, Shift is on the left, and I think that makes sense because I think on normal keyboards, the left Shift is the most frequently used one, and I think it would be the first place I would look, if I were to search for a Shift key.

The ' " key is on the right side of the keyboard on normal keyboards, so that's why I put it there.

Keep in mind that AltGr/Fn/Meta will be sticky (at least that's how it is on the Pandora and I see no reason at all to change that), so you don't need to hold it down while making a combination. You can press Meta, release it, then press U or Shift-U to get ü or Ü. So it is not necessary to hold down Meta, Shift and some other key at the same time (that would be hard to do with just two thumbs).

I would argue that keyboard Shift should be sticky too, for convenience.

Also keep in mind that the modifiers are also available on the shoulder buttons. So you can use your index fingers to hold any combination of Shift, Alt, Ctrl and Meta/Fn/AltGr, and still have two thumbs available to press keyboard keys. This would be the most efficient way to use modifiers anyway.

 

[_wb_]

_wb_, you make a good point about having a dedicated Tab because you often need to hit it repeatedly.  This is the same reason I prefer a dedicated Delete key.  I would need to try out using one that is brought out via a modifier to see if it is a problem, but my guess is that it will work fine, just slightly inconvenient.  I can't think of any common key combinations that use Delete, so those may not be a problem either.

Yes, a dedicated Delete key would be kind of nice. But a dedicated Insert key is kind of pointless (most people don't even use Ins at all), and since it also makes sense to have Ins and Del close to one another, you are forced to do something pointless (make Ins dedicated) just to do something nice (make Del dedicated).

On the other hand, Delete is probably one of those keys like Esc that you don't want to hit accidentally. It can after all cause files to be deleted and nasty stuff like that.

I like to have dedicated + and - for zooming (something you tend to do repeatedly), and also for --long-style-parameters, dashes (-- and --- in TeX), to make ascii separator lines like this ---------------------, to increment or decrement a variable (k--, c++). Not very important, but it's nice. Zooming is pretty important if all you have is a small screen.

Insert is critical for anyone communicating with TTY or IBM terminal emulation.  Ctrl+Ins is copy, Shift+Ins is paste.  Archaic, yes, but it does come up AND it's compliant with Linux via the Common User Access standard.

"The Cut command is ⇧ Shift+Del; Copy is Ctrl+Ins; Paste is ⇧ Shift+Ins;"

http://en.wikipedia.org/wiki/IBM_Common_User_Access

Yes, you can use those shortcuts. Ever since I use the Pandora, I don't use those anymore (the Pandora does not have Del and its Ins is an Fn key).

Most people just use Ctrl+X for Cut, Ctrl+C for copy, Ctrl+V for paste. That is also standard, and it works in nearly all programs I know. Only exception is the terminal, where you need Ctrl+C for interrupting programs with SIGINT. Most terminal programs use Ctrl-Shift-C and Ctrl-Shift-V. Or you can just select stuff with the mouse and use middle click to paste it.

My point is: yes, those shortcuts exist, but I see no reason why it should be particularly easy to use those shortcuts, since other shortcuts also exist which are more widely known and used.

 

[_wb_]

If the Pyra ends up getting only 1 Shift key, can we have that single shift key work like the FN key on the Pandora? What I mean is that you only have to press the FN key and not hold it down. You'd just press the Shift key, release, then press and you get a capital "S," for example. I'm very glad the Pandora has a shoulder button that works as a Shift key. Otherwise, I'd have a hard time Shifting the keys right next to the Shift button.

+1 on this one. Make Shift sticky by default.

 

[_wb_]

Okay I think there may be a way to make everyone happy!


Have a US + programming symbols keymap, however do everything else - even euro! Etc with a stencil that snugly fits over the keys


It might be possible to keep this in place even without any kind of clip, yet without fouling the keys...


On this stencil would be any special symbols needed only for a particular language


There could be for example a German one that would have a bunch of German language characters on it (the user would have to select with a utility the appropriate layout)


The German user could then using a convenient key combination (that would also clash with the other languages) could then type the special characters...


If made from a cheap enough a cosmopolitan user could pick up a Euro pack of stencils maybe for only a few Euros!


Now all we need is a forum thread for each language to come up with the stencil design... And more buckets of popcorn...

I'm not sure what you mean by "stencil", but how would this work with a backlit keyboard?

Unless you make the keys have a transparent (light) background with inked letters (instead of the other way around), it wouldn't work.

 

[WizardStan]

What I mean is that you only have to press the FN key and not hold it down.

This is called "sticky keys" and every system, including the Pandora, has the ability to do it. It's in the keyboard settings if you want to turn it on. I wouldn't recommend having it on by default but I use the shoulder shift for typing so I'm hardly the right person to discuss it.

Why not just sell blank keys and a paint/stencil kit?

Stickers!

 

[codifies]

Maybe the stencil could be transparent.... Perhaps...

 

[_wb_]

Here's another iteration of my compromise layout:

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

Changes:

• Meta and Shift both on the left now
• Punctuation (,.;) on the right now, near space (for easy combos)
• Reduced the number of symbols per key to 2, except on the number row. This also means that Meta+comma can be dead cedilla/ogonek (for those who need easy ç ş ą ę į ų) and Meta+period can be dead dot (for those who need ċ ġ ż ė)
• Made the labels for Ä € Ö Ü ß less prominent (a darker shade of the Meta color), this could be a good compromise in case the Germans really want explicit labels for their German letters.

 

[moxie]

I meant "accented" as in {ascii base-character that has extra bits in its graphical representation}, do you know a better word for it

I don't get what you mean? Is R the same as P with some extra bits in its graphical representation?

No, I mean diacritical marks on latin letters. I called them accents at first, because in French they are called "accent aigu" and similar. That is why I store all diacritics as "accents" in my head (I rarely have to talk about them, and consider the dots in ï to be "accents" as well). The gist is: there are many of those and you will not satisfy all Europeans with one keyboard layout (朌Æøéèëäüöïñãç, only from the top of my head). So why not print and write configurations for 4 or 5? If it costs that much more, then they could be extras, introduced later. I just dread the sight of an overcrowded keyboard with annoying dead keys and äs or üs. If the keyboard is produced like suggested I will reconfigure it and glue stickers on the keys or something like that.


I really resent your style of argument, instead of trying to make a point about the content of what I said (which is harmless) you are trying to find a technical flaw in how i phrased it. Who has ever suggested reproducing the R letter using a modifier and a P? What I said was way more accurate than what you pretend to derive from it.

No, my point is that you're missing my point To someone who has åäö in their language, å is no more a "latin letter a with diacritical marks" than R is "latin letter P with composed slash" or that w is "latin letter v, doubled". If it is to be a usable keyboard for anyone other than english-writing users, you need to have a correct model of keyboard/language usage, irrespective of the typographical details. Writing in nordic languages without having more or less equal typing conventions for r, å. g and ä is not usable. You cannot, in any meaningful way, write swedish, or finnish, or norwegian, or danish, text of any length if you have to use compose every time you want to write Ä. Pressing a fn/alt/meta/whatever key with the key works, and is also compatible with using shift the normal way (i.e. when keycombo gives ä, shift+keycombo gives Ä). I imagine the same thing would be true of writing german without ß, ä and ü. It goes back to what we want the Pyra to be, of course, but if we want it to be a machine usable for more than playing games, then those kind of issues must be dealt with.

(and of course, it rests quite a lot on EvilDragon being german, and thus being well entitled to make a machine that is actually usable for his own effin language. And the perennial arrogance that is "Well, duh, there's a standard, goddammit, and that's the standard right under my fingers, that is the US ascii standard that is the standard that is, and since I never use them funny furrign keys I can't see what the fuss is about! If it was good enough for Jesus, then it's good enough for everyone else!")

I like the position of the äöß and so on keys as they are now, and I think like B-zar that it is reasonable to call that block "international keys" or something, and then expect a good tool to switch in different highly used national keys there. I don't think it is worth it to try to move stuff to letter-likenesses (putting Ö under O), because that means more extensive remappings for different national mappings. That does not mean that we do not need a compose possibility - we need the ability to write glyphs that are not in our most used set, too - but there must be a possibility to make the keyboard minimally usable for writing text in non-english languages without having to play "hela havet stormar" with all the keys in order to fit the foreign characters in. A block of "international keys" does just that.

 

[Antartica]

Here's another iteration of my compromise layout:

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

I like this one a lot. Editing with vi and general command-line usage using that layout would be very nice indeed .

 

[Neelix]

If you leave that block of 'international keys' unlabelled then it would probably also make sense to have a few different included xmodmap files for various languages, which can be selected on first boot (or switched later through the config button) that configure that block for the selected language.

- Neelix

 

[moxie]

Exactly my thought.

 

[Magic Sam]

Hi all !

I'd go for a "standard" * US QWERTY keyboard, with dead and compose keys to accomodate everybody.

* with all keys necessary to work in a Linux environment.

That, or the Dzongkha keyboard layout

Cheers, Magic Sam

 

[jp10558]

Edit: Grench, I think you missed where ED said not to post completely different layouts.

Nope - didn't miss it.  However, I feel that the DosBox compatibility issues cannot be overcome with the Saber layout.  I see DosBox as a critical application for this emulation device.  Also, I feel that the need to be able to 'lock' and have easy access to Fn keys is pretty critical.

Those combined with the demands for a keyboard that has easily accessed keys for languages other than English led me to the layout I posted.

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

I'm pretty sure it meets the requirements as stated AND makes it compliant with DosBox.

I'm surprised you seemingly decided to make backslash a primary key, but forward slash a fn key combo. Won't linux use forward slash a LOT more than backslash? i.e. for paths etc?

 

[Mr_Loon]

A few questions for ED / the team on the Keyboard :

1) It is my understanding that the nubs do not now have a centre click, is this correct? If so it might be worth removing centre click from the description of nub actions.

2) What does Logo = Lid Notifications mean?

3) What would SysRq be used for?
_________________________________

Some general thoughts :

i) When labeling the keys use a label colour that has good low light visibility (i.e. don't use the same key label colours as Pandora)

ii) Having screen brightness adjusters on separate keys seems rather wasteful to me, why not have them on one key with a modifier?

iii) We are of course never going to find a layout to satisfy everyone with the layout but from a sales perspective it would make sense IMHO to base the layout on a US / UK keyboard as the biggest market for Pyra is likely to be the US / UK.

iv) The keyboard could really do with a dedicated companion application that allowed users to easily redefine keystrokes. This application could bring up via a dedicated menu key (perhaps instead of BR-), on the touch screen, a user defined list of required characters not printed on the keymat, they may be accented characters for French German etc., letters not covered by the 26 in the US / UK alphabet, local currency symbols etc.

v) The big one : Why on earth are mouse buttons not allocated by default to hardware buttons? Mouse clicks are one of the most commonly used forms of input, pretty sure a past survey of Pandora users showed that a significant majority would rather have dedicated hardware mouse buttons. I'd like to see the left and right mouse buttons set as the most easily accessible shoulder buttons and mouse movement on the right nub (like most people I'm right handed and use a mouse / trackpad etc. right handed).
 

From thinking about the whole issue of keyboard layout, a lot of the problems could be solved with a companion application that allowed easy remapping of keys / controls / buttons.

 

[rygD]

A few questions for ED / the team on the Keyboard :

1) It is my understanding that the nubs do not now have a centre click, is this correct? If so it might be worth removing centre click from the description of nub actions.

2) What does Logo = Lid Notifications mean?

3) What would SysRq be used for?


_________________________________

Some general thoughts :

i) When labeling the keys use a label colour that has good low light visibility (i.e. don't use the same key label colours as Pandora)


ii) Having screen brightness adjusters on separate keys seems rather wasteful to me, why not have them on one key with a modifier?


iii) We are of course never going to find a layout to satisfy everyone with the layout but from a sales perspective it would make sense IMHO to base the layout on a US / UK keyboard as the biggest market for Pyra is likely to be the US / UK.

iv) The keyboard could really do with a dedicated companion application that allowed users to easily redefine keystrokes. This application could bring up via a dedicated menu key (perhaps instead of BR-), on the touch screen, a user defined list of required characters not printed on the keymat, they may be accented characters for French German etc., letters not covered by the 26 in the US / UK alphabet, local currency symbols etc.


v) The big one : Why on earth are mouse buttons not allocated by default to hardware buttons? Mouse clicks are one of the most commonly used forms of input, pretty sure a past survey of Pandora users showed that a significant majority would rather have dedicated hardware mouse buttons. I'd like to see the left and right mouse buttons set as the most easily accessible shoulder buttons and mouse movement on the right nub (like most people I'm right handed and use a mouse / trackpad etc. right handed).

From thinking about the whole issue of keyboard layout, a lot of the problems could be solved with a companion application that allowed easy remapping of keys / controls / buttons.

The preferred nubs with center click were purchased in bulk, so the first few thousand units will be the original nubs, and this gives time to figure out what to do in the future.

The logo on the lid has RGB LEDs that will possibly be used for notification when the unit is closed.

#3 was answered earlier.

Keys will be backlit to assist in low light situations, however white markings (or lack of markings) will be used for primary character on each key.  Even other key markings should be visible in low/no light situations with backlighting.

Screen brightness keys have been discussed to death in other keyboard threads.  ED may or may not be open to changing things, so feel free to provide a solution you think maximizes other keys.

US and UK layouts are different, however the selected layout is primarily for English.

Redefining keys shouldn't be a problem and is already be discussed in this thread, including default language specific solutions chosen upon first boot.

Since the nubs click, and to maximize button use for missing keys, buttons are not used as mouse buttons.  You will probably be able to change to other buttons not built into the nub later.

 

[thatgui]

Screen brightness keys have been discussed to death in other keyboard threads.  ED may or may not be open to changing things, so feel free to provide a solution you think maximizes other keys.

Maybe one button with and "infinite increment": bl(=brightness level)1=>[press]=>bl2=>[press]=>....=>bln=>[press]bl1=>... ?