It's the keyboard layout.

[TrashyMG]

Strong vote for dedicated ESCape key (vim).

Honestly to me as a strong vim user it's such a non-issue on the Pandora, doing FN + Q is really not too difficult.  


having better grouping of slashes,colons and brackets seems like a better endevour.  

 

[the_marshal]

Completely agree about vim and ESC. It's a non issue for me and I am a pandora.

Also t's quite popular to avoid using the espace key in vim as it's out of reach when touch typing. I personnally try to use "ctrl + ]" instead.

http://vim.wikia.com/wiki/Avoid_the_escape_key

An interesting fact is that vim what initally developped on a ADM-3A terminal where the escape key is placed differently (well it's very different overall).

https://en.wikipedia.org/wiki/ADM-3A

 

[Grench]

Again, anything visual needs to be minimal, because more info, and especially non-standard info, is chaotic, and ruins everyones experience increasingly as you put everyones characters in.

I think you and I can agree to disagree on that one.

The human brain is far more adaptable than you are giving it credit for. 4 symbols in 2 colors on one key and having symbols that you don't recognize or use is a non-issue. I regularly use keyboards that have symbols in 4 colors, 3 of which are in a language I don't even pretend to understand. I never find myself wishing they weren't there or being confused by their presence.

If I'm going to re-code a particular key in the OS level, I would rather have -some- symbol on it than none at all. It's a lot easier to remember, "I mapped ¢ to Ü" than, "I mapped ¢ to the shift of the Fn of the blank key 4 in from the left. That is one of the reasons why I mapped a bunch of currency symbols to the otherwise unused Fn+key combinations on my layout. The additional symbols being present, even if not being used by a particular user, are a GOOD thing for usability.

Some people seem to be off put by having the German keys present in the Fn+key set. To me, it's more a, "Wow - that's cool. People from lots of backgrounds can use this with minimal pain." The attitude of, "I don't care if it's harder for them to use, they can all get bent because I can't stand to see symbols I don't understand or use even visible on MY device," is just plain ignorant.

Using the Fn+key and Fn+shift+key combinations in my layout opens up plenty of places for symbol assignments AND allows DosBox compatibility AND international use while trying to minimize their pain. There simply IS NOT ROOM on this keyboard to do P+2 and M+2 layouts. You're only going to touch type on the thing if your last name is in Elvish. Keys MUST share definitions in order to put even the 'standard English keyboard' keys all onto the keyboard without dropping several out.

The only key on my keyboard I could 'do without having mapped' is CapsLock. Since we have 2 shift keys though - shift+shift=CapsLock or Fn+shift=capslock should be a pretty easy solution.

It IS possible to have DosBox compatibility AND all keys from an English keyboard AND special characters for German and Spanish AND a dedicated DeadKey for diacritics all on the Pyra's limited key set.

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

What is -not- possible is to have it be 100% compliant with every language on the planet nor in the exact touch-type configuration that everyone seems to assume is possible. It is -not- possible to have a 'clean' layout that caters to multi-language usage. We -need- those additional symbol mappings if we're going to have even the complete English keyboard set let alone adding German and French and Spanish specific capabilities.

 

[moxie]

Would it not be best if the keys could be easily exchanged physically?
Then a set of keys for any language could be sold and people would just switch the keys around any way they like (and use the software support to match the physical layout).

Blank keys should also be available so we would paint the symbols on them we want.

Yes. World peace would also be nice

More seriously: That won't happen for cost reasons. A solution with individual keys would be much, much more expensive than one with a molded keymat as we have now.

 

[ible]

I might consider swapping _ and \, because _ may be used more than \.  Also, that puts \ next to |, which it is on a US keyboard.

I also am not as happy about =-+ not being close to a side, since that would be less nice for coding/math.  I'm finding it hard to rearrange things, however, with that extra shift on the face :blink:  .

What are the Key and Logo buttons doing up at the top while shifting?  It seems like the top row is all hardware-modifying keys, so it'd be nice to be consistent.  Also why wouldn't you use Alt-Gr to get to USB and BT?  I think it would be nice to use AltGr there instead of Shift.  Also, perhaps Shift + Br(+/-) could be keyboard brightness, and AltGr + Br(+/-) could toggle HDMI / power to LCD screen.  In that case, I'd prefer "Menu" to be Logo/Super.

None of the top hardware buttons have an AltGr value just in case someone wanted to turn on Bluetooth, Switch off USB power, or change key backlighting brightness while in AltGr lock mode. Shift was the better choice to alter them since we'll have two keyboard Shift keys. I would prefer Menu to be a dedicated Escape key. It's very easy to press Fn then Spacebar on the Pandora so hitting AltGr then Spacebar to bring up the Start Menu shouldn't be much of an issue for most. If L2 is also AltGr, then it's even easier. Backspace or Enter can take the place of the Menu key to do hard and soft resets and such.

I don't think it's a good idea to have an AltGr lock mode with your layout. It doesn't make sense as much as in Grench's (or my version of Grench's) layout.

I have already revised the layout on the first page. Consider it outdated. Equal sign is no longer too far inward. The results are shown in two new layouts in my signature. My posts dealing with ways of handling diacritics and some of my other ideas are also scattered around this thread's innumerable pages of tangents.

I'll consider it outdated if ED says so...

If you switch _ and = in your layout, the = will be closer to a side. Then = has a nice symmetry under - and +.

I wouldn't want an AltGr on spacebar. I would just drop the "Menu" button. It's much less important than Esc, IMO. I like the new position of Esc (taking place of Menu).

[edit]

Would you consider AltGr + R-shift (keyboard key) to be a compose key? Not sure if that makes things easier for diacritics peoples.

 

[Saber]

I might consider swapping _ and \, because _ may be used more than \.  Also, that puts \ next to |, which it is on a US keyboard.


I also am not as happy about =-+ not being close to a side, since that would be less nice for coding/math.  I'm finding it hard to rearrange things, however, with that extra shift on the face :blink:  .


What are the Key and Logo buttons doing up at the top while shifting?  It seems like the top row is all hardware-modifying keys, so it'd be nice to be consistent.  Also why wouldn't you use Alt-Gr to get to USB and BT?  I think it would be nice to use AltGr there instead of Shift.  Also, perhaps Shift + Br(+/-) could be keyboard brightness, and AltGr + Br(+/-) could toggle HDMI / power to LCD screen.  In that case, I'd prefer "Menu" to be Logo/Super.

None of the top hardware buttons have an AltGr value just in case someone wanted to turn on Bluetooth, Switch off USB power, or change key backlighting brightness while in AltGr lock mode. Shift was the better choice to alter them since we'll have two keyboard Shift keys. I would prefer Menu to be a dedicated Escape key. It's very easy to press Fn then Spacebar on the Pandora so hitting AltGr then Spacebar to bring up the Start Menu shouldn't be much of an issue for most. If L2 is also AltGr, then it's even easier. Backspace or Enter can take the place of the Menu key to do hard and soft resets and such.

I don't think it's a good idea to have an AltGr lock mode with your layout. It doesn't make sense as much as in Grench's (or my version of Grench's) layout.

I have already revised the layout on the first page. Consider it outdated. Equal sign is no longer too far inward. The results are shown in two new layouts in my signature. My posts dealing with ways of handling diacritics and some of my other ideas are also scattered around this thread's innumerable pages of tangents.

I'll consider it outdated if ED says so...


If you switch _ and = in your layout, the = will be closer to a side. Then = has a nice symmetry under - and +.


I wouldn't want an AltGr on spacebar. I would just drop the "Menu" button. It's much less important than Esc, IMO. I like the new position of Esc (taking place of Menu).


[edit]


Would you consider AltGr + R-shift (keyboard key) to be a compose key? Not sure if that makes things easier for diacritics peoples.

To answer some questions and some elaboration:

AltGr Lock like Fn Lock on the Pandora has it's uses for some people, but yes we don't necessarily need to have it or a CAPS Lock key.

Of course as always it's ED's final decision on what the layout will be. I do think the one posted on the first page is improved upon in my v2b and v2c modifications in my sig.

Having Compose on Left Shift + Right Shift(keyboard or shoulder) is the more appropriate option instead of AltGr + Right Shift. We already have an AltGr value on Left Shift, so I'd like for the other Shift key to remain empty under AltGr... I don't want to start piling modifiers on top of modifiers.

I'm glad you agree with me about Escape. Others may disagree with us, but as I see it in order for a real no hassle no modifiers needed Escape key, putting Menu on AltGr + Spacebar is an ideal solution. While I have no problem with AltGr + q for Escape, others see it as a barrier to their productivity to have to press two keys.

In some emulators, Escape is often used to exit the program, so placing Escape with the game controls Start and Select does make some sense. Having it close by yet away from the other keyboard keys also seems reasoned because of how absolute the Escape key is. You'd never mistakenly hit the Escape key if it's where Menu is and honestly Menu for the sake of opening the Start Menu and some shortcuts(Backspace or Enter could replace it) doesn't deserve it's own primary key even if the Pandora utilized it for the sake of having the logo front and center(which is now also emblazoned on the lid in full glory).

While = and _ can be swapped, some may want it to stay the way I have it. According to the information in this post, underscore is a little more popular overall.

The Acute can as Askarus suggested replace Euro. The umlauts can later be remapped then according to the user's particular needs.

Finally, the square and curly brackets are arranged like { [ ] } because that is how they are on a German keyboard. Some may want them paired as {} and [] and this may still be possible but honestly they are aren't too much different to get used to. 

 

[ible]

Underscore may be more popular in regular writing, but many lines of code have = in them...

For coding, I would thus prefer that, especially because of the symmetry with - and +.

Question, what is the squiggle s looking thing?  (Not the esset.)  Who uses it? 

 

[comradekingu]

Grench: Just because more visual information than is needed isnt a problem for you doesnt mean its not a problem for me. Or someone else. I think we can agree that a simple visual layout caters to everyone. To illustrate the problem, here is colemak with AltGr printed https://upload.wikimedia.org/wikipedia/commons/f/f1/KB_US-Colemak_with_AltGr.svg

Why would you put german letters in nonstandard places with nonstandard input method instead of having both of those the regular way. What german would use that over the other?

M+2 cant be done, because there cant be 6 keys assigned to language and also easily swapped.

P+2 along with L+2 is how you get the most languages within the scope that we are given.

That is international use. Stringing keys together, special combos to type regular letters isnt, its different from regular use. You can of course also do that, no issue there. Combine the two for more power.

If you strip away dedicated keys, you are for any language other than english making typing more difficult. It isnt always 100%, but many times it is, German, Spanish, French, Danish, Swedish, Norwegian, more importantly, its the closest thing you get to 100% for everyone. Without any drawback to the ones you cater to in the first place, which is English.

Its as easy as this, if you put the cap at 26 letters then you include english. If you put the cap at 29-30, then you include all of the above and make it a bit easier on those who didnt make the cut.

Shift+shift being caps lock or fn+shift being caps lock, is a simple solution, and it creates a complex problem. What if you accidentally caps lock ON, and want to turn it off? That would be enough to confuse me to the point of needing a manual. I think that should be as little as possible, or avoided completely.

Also i think assuming that any solution is equivalent and that the only decider is use is not true. People do pass up buying something over bad or ill-fitting keyboard-layout.

 

[Grench]

Grench: Just because more visual information than is needed isnt a problem for you doesnt mean its not a problem for me. Or someone else. I think we can agree that a simple visual layout caters to everyone. To illustrate the problem, here is colemak with AltGr printed https://upload.wikimedia.org/wikipedia/commons/f/f1/KB_US-Colemak_with_AltGr.svg

Neat keyboard. Won't even remotely work in our confined keyboard.  We simply do not have room for dedicated keys with 5 variations of 'A'. Note that your example has no F1-F12 keys taken into account.  However, it has the right idea.  It, like the Pyra, must fit as much functionality as possible into the limited space available.  In order to make that functionality usable, it needs to be labeled appropriately with symbols matching the key functions and combinations.  There is nothing wrong with that. 

A 'simple visual layout' is pointless - you may as well remove ALL labels if that is your intention. Having keys labeled with the symbols they generate caters to everyone who plans to actually use the device. Those wanting something to sit on a shelf under glass may think it's ugly, but that isn't the Pyra's audience.

Why would you put german letters in nonstandard places with nonstandard input method instead of having both of those the regular way. What german would use that over the other?

Because the 'standard places' do not allow a contiguous set of F1-F12 keys. Also, this would shift the keyboard left to the point where there is no longer any room for the needed modifier keys on the left side to match the right shoulders.

M+2 cant be done, because there cant be 6 keys assigned to language and also easily swapped.

Hey, at least we agree on that. There simply isn't room for it.

P+2 along with L+2 is how you get the most languages within the scope that we are given.

And how we end up with a messed up F1-F12 key row and lack of room for Alt, Ctrl, Shift and Fn and having to eliminate Ins and Del and having to eliminate room for any other keys on the left. It isn't brilliant.

That is international use. Stringing keys together, special combos to type regular letters isnt, its different from regular use. You can of course also do that, no issue there. Combine the two for more power.

I could see potential is rearranging the Fn+key modifiers on my keyboard for greater efficiency to a point. However, the current design WAS intentional and not random. You'll notice that Fn-letters are on the left side and Fn-symbols are on the right. The symbols pairs are also roughly in the order that they appear on a standard US keyboard - though they may have dropped down a row and over 2 spaces. Each Fn-symbol is a pair to enable DosBox compatibility. Forcing German letters onto their AltGr standard keys would dictate scrambling the F1-F12 keys around the keyboard AND making the symbol key order from it's current logical layout into a scrambled mess. Per ED's instructions, this was designed as English First (thus the positioning of the symbol keys from the right of the English keyboard to Fn positions on the right side of the keyboard). He also requested compatibility with German and French - taken care of on the Left side. I also added Spanish since I had room for the 4 needed characters/symbols.

If you strip away dedicated keys, you are for any language other than english making typing more difficult. It isnt always 100%, but many times it is, German, Spanish, French, Danish, Swedish, Norwegian, more importantly, its the closest thing you get to 100% for everyone. Without any drawback to the ones you cater to in the first place, which is English.

I didn't strip away dedicated keys. I added them. The order may be different from a full sized non-English language specification, but they're present and labeled. The order/placement MUST change in order to include all of the needed 'computer keys' AND give logical placement to the modifier keys and punctuation/symbol set from the English keyboard.

Its as easy as this, if you put the cap at 26 letters then you include english. If you put the cap at 29-30, then you include all of the above and make it a bit easier on those who didnt make the cut.

Did you notice that your layout doesn't work for English, general computing or DosBox? By eliminating so many symbols and mixing unshifted/shifted key pairs to other keys, functionality suffers badly.

Shift+shift being caps lock or fn+shift being caps lock, is a simple solution, and it creates a complex problem. What if you accidentally caps lock ON, and want to turn it off? That would be enough to confuse me to the point of needing a manual. I think that should be as little as possible, or avoided completely.

Please, I know you're not dumb. If shift+shift = CapsLock (or Fn+Shift = CapsLock) then doing it again toggles it off. Are you REALLY that easily confused?

Also i think assuming that any solution is equivalent and that the only decider is use is not true. People do pass up buying something over bad or ill-fitting keyboard-layout.

I agree. The keyboard layout should have maximum functionality for as many people as possible (Good layout, compatibility with DosBox, presence of symbols for expected languages). It should fit (be relatively centered) and be 100% functional as a thumb-keyboard.


What it shouldn't be is stripped of symbols to the point where nobody knows what they're hitting. It shouldn't shuffle symbol-pairing (needed for DosBox) to random places simply to make it more aesthetic.


Usability and function MUST trump simplified aesthetics or we may as well all go buy an iPad. They're gorgeous and completely unusable for what the Pyra needs to be able to do.

 

[comradekingu]

But those people dont plan to use the device in the way you imagine. Non-dedicated buttons is useless for a great deal of people.

The point of the colemak image was to illustrate information overload, a very real concept.

How does F-1 to F12 fit into the numbers row, and why does it have anything with A on the leftmost key or the second to leftmost key?

If you look at the keyboard vote, people dont want F-keys on the QWERTY-row. Most notably because those two rows dont align like on a regular keyboard.

Does it at all bother you that putting function keys on the left is demonstrably inefficient? We dont have the use of the pinkey-finger. If you do decide to use all 10 fingers then you have yourself a bad 10finger keyboard. Normal operation should not suffer because of that.

You didnt add dedicated keys, you added the symbols from those keys, in other places. Every functional layout, all ISO-keyboards, have

the ØÆÅ or ÎÄß or what corresponds to that language, in the same places, dedicated keys, in those places, is how a keyboard works.

German, Spanish, Danish, Swedish and Norwegian uses the letters you put in on ASDFZXCV. I speak all those languages well enough to tell you that it doesnt work.

Its comparable to the inefficency you add by going from english on T9 keyboards to international on T9 keyboards. Its extra presses to get to where you want. The whole thing screams lack of buttons and toy-keyboard.

Please prove how my layout doesn't work in my thread.

I can easily press shift and don't know that i bumped a shoulder too, thats very plausible. Clinch the whole device and you wont now what sequence of keys you press.

SDGJNKJGDSNKJNDGFK  if thats Caps lock on, and insert-mode, and compose, then you have created a problem, because its all made up. It isnt how a keyboard works.

People know what they are hitting. AltGr+letters produces symbols in europe and elsewhere in the world except the US/UK. Those arent written and that works. Because they aren't used much. and also because keyboard use is about motorical learning. Not visual sorting.

The reason the international users say they want buttons that are either unlabled or not cruzial to language-typing in the area those keys are supposed to be is because thats the keyboard to them. The one they know how to use, and the one that is the most effective.

What symbols are you missing?

 

[Saber]

Underscore may be more popular in regular writing, but many lines of code have = in them...

For coding, I would thus prefer that, especially because of the symmetry with - and +.

Question, what is the squiggle s looking thing?  (Not the esset.)  Who uses it? 

The squiggly symbol is called Section Sign. On the Pandora, the Yen occupied the place where § is now in the layout and was known humorously as the "remap key". Section Sign will likely serve the same purpose. 

We should keep in mind AltGr + u, i, j, and k could theoretically be mapped(or not) as umlaut, circumflex, grave, and acute dead keys if ED decides to do so, but it's more probable it will be at the user's discretion to make these types of changes when they receive their own Pyra.

About the layouts, it wasn't coincidence all the Umlauts, Euro, Section Sign, and Micro Symbols are all clustered together like they are. It also wasn't by chance the brackets, mathematical symbols, and main punctuation are bunched all toward the left. This keyboard layout will function without the user ever needing to trigger any of the shoulder button modifiers if they choose not to(common preference). 

Anyways, hope you and others like them in a preliminary sort of way. 

 

[DAP]

I think the losers are dvoraks, or something else where you need to use M+2 for typing, but that is the minority in this case. One that unfortunately cant be fully happy with the compromise that works for everyone else (given how you have print on the letters (pretending remapping is ok isnt ok. It is for the dvoraks, but they are very few, and the people you sell a lackluster M+2 idea to isnt a huge bonus)

Thank you so much for dismissing me as a "minority". As a Dvorak typist, that double wide space bar is the ONLY thing I care about. Getting rid of it would be a minor inconvenience to about 10% of the normal typists, but would make my keymap possible. With it there I won't be doing much typing on the Pyra, and it will be much less useful to me.

At least lefties can buy left-handed scissors & mice.

 

[rygD]

I don't think comradekingu's comment was intended as a snub.  It seems he was actually trying to acknowledge that there are dvorak users that might want to remap, and that the selected layout would be unsuitable for reasons as he understands them.  Being a minority is based on statistics, and dvorak users are a minority, thus not a priority, as are those like myself who sometimes type with a handheld device on a desk/table, and not in their hands.  I have seriously considered switching to dvorak, however I don't want to feel crippled when switching back to qwerty since there are times when I need to work fast, and fumbling around while trying to get used to qwerty again is not worth it to me at this time.  I already type in some random, wild way, and cannot be seriously called a touch typist since I cannot keep my fingers based on the home keys without losing speed and accuracy.

There are many advantages to a singlewide space "bar", including an extra key that could be extremely valuable for all layouts.  ED has already made the call that the keymat will have a doublewide space bar, however this does not prevent owners from changing their layout, including splitting the spacebar.

 

[bzar]

Saber: Given the recent talk about Fn being actually required to have some applications work right (so for example F1 produces a single keypress F1 and not altgr+1), I'd suggest moving altgr to where the right shift is and putting Fn to the bottom right. Use Fn for keys that exist in US ASCII and AltGr for keys that do not.

 

[slaeshjag]

^ That would be sub-optimal in many ways.

First of which is the confusion of having two different modifiers yielfing different results. There will be no way to print on the keymat which is which. At least not with colors.

Secondly, only one modifier will be possible to put on a shoulder button. And that's a war I don't want to see.

 

[bzar]

Well, I guess only non-modified and Fn-produced keys would be printed. I could live with that.

I'd put AltGr on the shoulder as I'm quite sure it would be technically more difficult to put Fn there. Fn needs to be implemented on driver or hardware level, while any evdev device can output software modifiers. Putting Fn on the shoulder would mean the same driver for game controls and keyboard, which I'm guessing is not the case.

 

[Neelix]

Would use of Fn for the standard US keyboard symbols and AltGR for the international symbols that mean we could get away with setting the keyboard layout as a modified "US international", and using that to determine the default international character layout?

- Neelix

EDIT: I may be biased here as US international is what I use normally,  so I'm fairly well familiar with it.

 

[codifies]

Even peeps not in the US use a US layout for programming (not exclusively but commonly) a US layout with other programming symbols should be the only permanent mark on the keymat - allowing users from multiple countries to layout the keyboard how they like without them tripping over a third language they have no need for...

Extra symbols can be printed on the case or a removable overlay, allowing the same unmodified machine to be used in a wide range of languages without all languages being inconvenienced by other languages they have no need for

 

[bzar]

In my experience those people [that use a US keyboard for programming instead of their local one] are more an exception than the rule. During my entire career in SW development I've only seen ONE person do this.

 

[Saber]

Saber: Given the recent talk about Fn being actually required to have some applications work right (so for example F1 produces a single keypress F1 and not altgr+1), I'd suggest moving altgr to where the right shift is and putting Fn to the bottom right. Use Fn for keys that exist in US ASCII and AltGr for keys that do not.

From what I know of it, ED wants one third-level modifier to access the symbols and F-keys; a tailored for the Pyra AltGr. As ptitSeb said in this post, it's about adaptation and I think the software, in those cases where it's even an issue, should be adjusted to work with the hardware not the other way around. DOSbox and QEMU share the same "bug" with colon and semicolon but there's apparently an unreleased workaround to remedy it.

This is a new machine and it's to be expected not everything will transition smoothly over to it, but I'd say we have enough modifiers already.