It's the keyboard layout.

[WizardStan]

Also a good counter-counter-argument.

 

[codifies]

by putting a character on a keymat key you in effect fixing its function in concrete

The counter argument is that by putting a character on the keymat it makes it easier to remember what you've changed the function to. Like "I replaced the yen symbol with an accented A" or something. There's good reasons on either side for whether to more fully pollute keys or not.

fixed your typo for you...

once something is on the keymat it cannot be changed, and there will probably only ever be one keymat...

easier to remember where the á is if you have written á on a removable template over the A key, or are using a pre-printed tempate with an á above the A or you have the Spanish version of the case with á printed on it

If á is on the keymat then its there in the way for all the other people in the world who don't need an á and its a keymap forced on the whole world forever....

 

[comradekingu]

So by doing something non-standard, it is decidedly different from keyboard standard.

-Because its not a standard keyboard..

Isn't that whats making it a non-standard keyboard?

It looks somewhat manageable with a cheat-sheet visible, without that, not so much.

For example, shoulder-modifiers are good and all, but if they arent marked, then that fails.

Not marking them because that is not standard shoulder behavior or some other such argument, isnt going to change that.

 

[_wb_]

by putting a character on a keymat key you in effect fixing its function in concrete

The counter argument is that by putting a character on the keymat it makes it easier to remember what you've changed the function to. Like "I replaced the yen symbol with an accented A" or something. There's good reasons on either side for whether to more fully populate keys or not.

I accept that counter argument when talking about completely blank keymats. However, every key will get at least one label already. I don't think it's particularly more difficult to remember, say, "I put å at Meta+A", than it is to remember, say, "I replaced ä with å". The primary label can be enough as a mnemonic, and it will work better as a mnemonic if the keymat is not littered with labels that are no longer correct in your customized layout.

As a compromise, I could imagine that we could have the default Meta-labels for those non-ASCII letters printed on the keys in a less prominent way, say, a darker shade (e.g. 50%) of the auxiliary color. That way they add less visual clutter and it feels slightly less bad to modify them.

Edit: Oops, I replied too fast. Neelix already made my point.

 

[_wb_]

So by doing something non-standard, it is decidedly different from keyboard standard. -Because its not a standard keyboard.. Isn't that whats making it a non-standard keyboard? It looks somewhat manageable with a cheat-sheet visible, without that, not so much. For example, shoulder-modifiers are good and all, but if they arent marked, then that fails. Not marking them because that is not standard shoulder behavior or some other such argument, isnt going to change that.

Yes, shoulder buttons should be clearly marked as modifiers this time. It's especially important since we have twice as many of them now. Same with the action buttons.

The labels in my proposal (http://www.keyboard-layout-editor.com/#/layouts/850cafe5b869738793f25ac95d73e2f9) are meant to show the actual markings, modulo typographic improvements and better label alignment. If the shoulder buttons are too small for those labels, then I would rather drop the L1 / L2 / R1 / R2 labels than to drop the ⇧ / ◆ / Ctrl / Alt labels.

 

[Grench]

by putting a character on a keymat key you in effect fixing its function in concrete

The counter argument is that by putting a character on the keymat it makes it easier to remember what you've changed the function to. Like "I replaced the yen symbol with an accented A" or something. There's good reasons on either side for whether to more fully populate keys or not.

Mnemonics - they work.

I don't think it's a good idea to let the Pyra keyboard try to look completely like a standard keyboard for which you can use standard xkb layout files, because it simply is not a standard keyboard.

What's a standard keyboard ? a 104 ANSI, a 105 ISO, a 109 JIS, a Tenkeyless, a 70%, a 60%, a 40%, a thumbshift, an Apple keyboard, an Ergodox ? There is no norm, no standard, just some consensus more or less followed by manufacturers since the 60's IBM modern typewriters (like the odd 2 right hands row shape instead of the early "brick wall" shape). Only the keycodes assignment is a standard and every keyboard follows them.


If you want to make a "azqwertzy-international" make a classic legacy us-qwerty layout, with all the standard keycodes provided, that let the layout easy to change with xkb. It will make less work to import the layouts than to rewrite them.

There is no unique layout that suits every language, even with concentrating your effort on Roman alphabet only : it will be extremely suboptimal. Bépo is a great exemple of what it's possible to do with dead letters, it covers a lot but not efficient at all and focused primarily on French language and typography. Colemak did a multilingual layer too but very limited. In such a keyboard, if you don't work with more layers like Neo v.2 does or dead letters like acute, agrave, dead_cedilla or dead_macron you have no chance to cover such different languages as Spanish, Türkish, Icelandic and Czech.


It's the same for programming : every language has its own syntax and PHP or C++ or Perl or sh developers have particular needs.


As I said, the perfect layout is the one you made to suit your needs so let people make their own.

And....  we're reduced to less than stickers and having every Pyra shipping with an ultra-fine Sharpie marker AND needing a bios level keyboard mapping utility.

 

[Grench]

So by doing something non-standard, it is decidedly different from keyboard standard. -Because its not a standard keyboard.. Isn't that whats making it a non-standard keyboard? It looks somewhat manageable with a cheat-sheet visible, without that, not so much. For example, shoulder-modifiers are good and all, but if they arent marked, then that fails. Not marking them because that is not standard shoulder behavior or some other such argument, isnt going to change that.

Yes, shoulder buttons should be clearly marked as modifiers this time. It's especially important since we have twice as many of them now. Same with the action buttons.

The labels in my proposal (http://www.keyboard-layout-editor.com/#/layouts/850cafe5b869738793f25ac95d73e2f9) are meant to show the actual markings, modulo typographic improvements and better label alignment. If the shoulder buttons are too small for those labels, then I would rather drop the L1 / L2 / R1 / R2 labels than to drop the ⇧ / ◆ / Ctrl / Alt labels.

I generally like this design.  A few minor things to examine?

Brightness controls on your modified Ins and Del buttons - is that for the keyboard or screen backlight?  What controls the one that those are -not- for?

There may be an issue in the dead key diacritics methodology.  Meta+symbol works for most, but what if the symbol needed is ` or ~?  Those already reside at a 'meta' level - and it can't meta+meta+symbol...?

 

[_wb_]

So by doing something non-standard, it is decidedly different from keyboard standard. -Because its not a standard keyboard.. Isn't that whats making it a non-standard keyboard? It looks somewhat manageable with a cheat-sheet visible, without that, not so much. For example, shoulder-modifiers are good and all, but if they arent marked, then that fails. Not marking them because that is not standard shoulder behavior or some other such argument, isnt going to change that.

Yes, shoulder buttons should be clearly marked as modifiers this time. It's especially important since we have twice as many of them now. Same with the action buttons.

The labels in my proposal (http://www.keyboard-layout-editor.com/#/layouts/850cafe5b869738793f25ac95d73e2f9) are meant to show the actual markings, modulo typographic improvements and better label alignment. If the shoulder buttons are too small for those labels, then I would rather drop the L1 / L2 / R1 / R2 labels than to drop the ⇧ / ◆ / Ctrl / Alt labels.

I generally like this design.  A few minor things to examine?

Brightness controls on your modified Ins and Del buttons - is that for the keyboard or screen backlight?  What controls the one that those are -not- for?

There may be an issue in the dead key diacritics methodology.  Meta+symbol works for most, but what if the symbol needed is ` or ~?  Those already reside at a 'meta' level - and it can't meta+meta+symbol...?

They're for the screen backlight. The keyboard backlight could be tuned with Shift+screen backlight, and perhaps also from the on-screen menu accessed with the Hardware key. E.g. the shortcut could be Hardware+K to toggle the keyboard backlight (presumably you mostly just want to toggle it, not tune the exact brightness level).

About the dead key diacritics: only acute (at ') and umlaut (at ") are available as dead diacritics in this layout. Arguably those are the most important ones. For the others you would need to use Compose (three thumb presses instead of two with dead diacritics), or you would map the precomposed letter to one of the available Meta+letter keys.

This is why I suggest in my "default mapping" proposal to put the precomposed graves àèìòù at Meta positions (I put them at Meta+QWJIY, respectively, with the mnemonic idea being that it's always a key to the left of the actual letter that gets the grave, while the letter itself is reserved for the precomposed German umlauts äöü and €), and to put dead circumflex at Meta+V, which means that the next two important diacritics (grave and circumflex) are also easily available. Dead versions of cedilla and tilde are only really needed for ç and ñ, so having those two precomposed at Meta+CN makes sense.

 

[lennaick]

With your keyboard if I want to make « ê » I press shift+6 in order to have the « ^ » and the key « e » right ?

 

[codifies]

Are we even sure the key matrix can cope with multiple simultaneous keys like that... For example my laptop can't cope with certain simultaneous keys like a & w together...

 

[dimag0g]

Posting to this topic should require a 5$ donation for the Pyra keymat mold. That way ED will have enough money for it in no time

 

[blip]

And....  we're reduced to less than stickers and having every Pyra shipping with an ultra-fine Sharpie marker AND needing a bios level keyboard mapping utility.

There is no BIOS on ARM arch and keycodes depends on the keyboard controler but I still don't know where this part is on the main board and anybody here seems to know that since I had no answer during the last two days.

So I rephrase : Does anyone knows where the keys' traces goes and how work the controler associated with them ? Is this directly controled by the Omap5 with something like uEnv.txt or later in the OS ? Thanks for the reply

Layout could be printed on a thin plastic sheet (laser printed or even with a classic inkjet printer) sandwiched between the Pyra and the clipped keymat (with transparent buttons). No glue, no stickers, no marker pen involved.

Are we even sure the key matrix can cope with multiple simultaneous keys like that... For example my laptop can't cope with certain simultaneous keys like a & w together...

Seems to have no places for one 1N4148 diode per key on the PCB so assuming it's a matrix, the keyboard isn't NKRO.

 

[rygD]

I would be very amused if we did get a blank keyboard, especially since they went to all the trouble of ensuring it would be backlit this time.

Posting to this topic should require a 5$ donation for the Pyra keymat mold. That way ED will have enough money for it in no time

Is this per post, or do we pay once and get to post as much as we want? 

I really should donate, though, not that what I can give will have much impact on the overall production costs.

 

[codifies]

The April 1st keymat design + interchangable printed overlay - is the way to go...

 

[comradekingu]

by putting a character on a keymat key you in effect fixing its function in concrete

The counter argument is that by putting a character on the keymat it makes it easier to remember what you've changed the function to. Like "I replaced the yen symbol with an accented A" or something. There's good reasons on either side for whether to more fully populate keys or not.

I accept that counter argument when talking about completely blank keymats. However, every key will get at least one label already. I don't think it's particularly more difficult to remember, say, "I put å at Meta+A", than it is to remember, say, "I replaced ä with å". The primary label can be enough as a mnemonic, and it will work better as a mnemonic if the keymat is not littered with labels that are no longer correct in your customized layout.

As a compromise, I could imagine that we could have the default Meta-labels for those non-ASCII letters printed on the keys in a less prominent way, say, a darker shade (e.g. 50%) of the auxiliary color. That way they add less visual clutter and it feels slightly less bad to modify them.

The reason blank keyboards work is because they arent different from the main way keyboards work, you only have to deal with this:

• Missing labels
  

This is orange, because it can go either way. At best position only is fully good, or better. Better for people who type a lot, but a total fail for newcomers.

Difference of printing labels in places they dont belong:

• the letters (clutter) for people whom they dont belong to (alienating)
  
• expected functionality doesnt work.

The interlingual functionality belongs in the right half of the right half of the keyboard.

Interlinguals implemented in a per-key basis  fails because:

• a lot of languages (like french) use multiple a's.
  

So just because letting it be up to the user is less of a ugly hack than doing the ugly hack by default, doesnt mean it works. See AltGr at bottom. See ways to type

These deviations from how to type are inefficient because

• It's a learning process, people dont want new, especially re-learning something you already know.
• not having dedicated keys is inefficient as a typing process
  

There is only one way to fix that, because it only works the exact same way on every keyboard that works. Full typewriter or bust.

Hiding clutter by de-visualising symbols in places they dont belong is adding insult to injury

•  harder to find symbols
  

Scanning low-visuals on the whole typewriter area is worse than scanning good visuals on the numbers area. Good visuals on standard numbers area would be optimal, but thats when we lack keys. Rearranging is a whole lot better compromize than spreading them all over. I never get over it, and i forget if i havent used the pandora in a long while. If we want a big community, we cant rely on some of the things that makes the current community smaller. New people, especially the ones who arent oversold on the idea already, dont put up with as much hassle.

"I dont follow the standard"  a selection of arguments that have been presented throughout this thread.

Spoiler

• There arent enough keys.

If you arent _trying_ to adhere to the standard, any standard doesnt matter, you are making your own. One that does more than what needs to be done. See frog.

• Its a two thumb keyboard.

Sure, did it get better or worse?

• Less distance traveled typing often used combinations
  
• Breaks expected functionality.

Its not fully standards compilant

• Less standard compilant
  
• More standard compilant
• Fully standard compilant

                 Making it less standard and arguing that this was part of the problem that is now made worse, doesnt make sense.

• Its not a desktop keyboard

Nor is a frog, but one of them is a keyboard all the same.

Putting a frog on the keymat is also different from a desktop keyboard, typing on a frog does not for a good keyboard make.

Exchange frog here with any arbitrary deviation from something that works.

• The openpandora did it!

A whole lot of people experience this layout as _broken_, to the point where they dont use the pandora over it. If you arent one of those people, then dont appeal to prior practice because prior practice works only for you. That is excluding people, to the tone of half the audience.

We dont know who did it on the openpandora, nor why, but in retrospect we do know that a lot of the things are worse than neccisary or ill-deviced.

• Having AltGr on shoulderbutton only means its harder to type third level modifiers than it is to type non-standard second level modifiers only.

Fantastic argument! While true, the effect can be lessened by not putting language-centric stuff on third level modifier.

The poll suggested "No, it's OK if some modifiers are only available as shoulder buttons" that AltGr not on the keyboard is fine, and my vote favored " Only require shift to input natural language. (Semi standard arrangement on number row)".

With the symbols on numbers _having_ to be different, this is fixing the main issue new people have with keyboards. They dont know how to use the AltGr.

Also, consider this, for the people who do know how AltGr works, there are default combinations of AltGr+typewriter keys. This does a lot of nifty stuff, like typing đðþ€ß and whatnot, it is expected behavior, and it solves a lot of the "i need foreign things" for each region.

I do argue that doing modifiers on shoulders, and especially non-keyboard AltGr, even if you rely on it less, _has_ to be printed on the shoulders. We need to get some clarity on that.

Just like it wasnt optimal to do without keys to have dedicated keys, and similar to how its not ok to take away from the english to accomodate international, we need to investigate further as to what can be done here.

The standard is what exists, and what works. Do something that is not known to work, or as in this case, known to fail, then who is left to benefit?

These are my goals:  

Make it as beginner-friendly as possible, exclude the least amount of people.  Can we just vote over it ? to see where current proposals stand, and if the prior voting holds true.

 

[ible]

Vote:

http://boards.openpandora.org/topic/17977-unofficial-keyboard-poll/

 

[_wb_]

With your keyboard if I want to make « ê » I press shift+6 in order to have the « ^ » and the key « e » right ?

No, Shift-6 just gives ^ as an ascii character. You can press Compose, then Shift-6 and "e" to get "ê", but that's a bit cumbersome. That's why if you often need circumflexes, it's better to have a dead circumflex somewhere (e.g. Meta+V or Meta+ B) , or even map precomposed circumflex letters, e.g. you could map éêè to Meta+WER for optimal efficiency.

Here's my proposal, with the default mapping indicated in a darker shade of the auxiliary color:

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

It has dead circumflex at Meta+B (for âêîôû) and dead caron at Meta+V (for čšžřňľěǧȟŤĎ). The caron is quite important for the Balto-Slavic languages, so it makes sense to have it too.

 

[ible]

This is a great point for the _wb_ line of keyboard layouts (mine is a descendant). you can put in all these dead keys by default, but they do not scare anyone by requiring prints on the keyboard.

for layouts which do not have open keys (Saber's), these letters would be harder to use.

for layouts which have many diacritics but not all (Grench's), this would be less of a problem.

 

[Saber]

This is a great point for the _wb_ line of keyboard layouts (mine is a descendant). you can put in all these dead keys by default, but they do not scare anyone by requiring prints on the keyboard.


for layouts which do not have open keys (Saber's), these letters would be harder to use.


for layouts which have many diacritics but not all (Grench's), this would be less of a problem.

For the record, AltGr/Meta symbols in my layout are printed(in a non-frighteningly way) by default on the physical keycaps but can be changed to whatever the individual wants them to be, including dead key diacritics.

Really, remembering AltGr + i was ß in my keyboard but is now remapped to ç should be just as easy to recall as AltGr + i was blank but is now ç.

 

[_wb_]

What about this?

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

Comradekingu and Grench and probably others have proposed a similar thing in the past. Use an inverted color scheme where most of the button is transparent and only the label gets ink.

Main advantages:

• It becomes possible to add labels to the keys, by printing an overlay on some kind of transparent plastic sheet, or simply by using a suitable pen and manually writing stuff at the bottom of the keymat. Ultimate physical customability!
• Less backlight brightness is required, saving some power

Main disadvantage:

• This color scheme might look cheap or weird.