It's the keyboard layout.


I also think that ßÄÖÜ should be unlabeled as it's useless because you just have to put them on BAOU and everybody will remember.

3 shift is an overkill as everyone will always use the same or maximum two. I'd replace one by a dedicated Esc key.
 Everyone who has to use that solution will remember how dysfunctional it is. Every time. Two shifts is the optimal solution, since one is close to dot and enter, and can be used for "on the desktop typing" the other is shoulder.

BAOU+ what? AltGR(does something else), Meta (you run out of options for variations of what you call a's quick)

Position is everything on a keyboard. Try listing out all the keys on the ASDF-row. Its not easy even if you use a keyboard every day. Its all muscle-memory.

When you break that convention, you fail. I wish it wasnt the case, but it is. At the same time, if you just happen to do it right, it works.

All thats needed is the keys, and you can switch language and touch-type just the same. Works also for less experienced users.

Nah, I think 3-4 keys are enough for the most used letters, not all of them.
French keyboards have dedicated keys for é è ç à ù, and a dedicated dead key circumflex and diaeresis.Polish keyboards have Ł ż ą ó ś ń ć ź ę.

Spanish keyboards have ç ñ ¡¿ and dead acute, grave, circumflex, diaeresis.

Italian keyboards have à è ì ò ù ç é.

Czech keyboards have ě š č ř ž ý á í é ů ú.

Hungarian keyboards have ö ü ó ő ú é á ű í.

Can you for each of these languages tell me precisely which 3-4 keys would be enough? ;)
Shouldnt we instead accomodate as many as possible? I think even if you use more than n number of extras,any number of extras makes it an easier job to re-map. Without it turning into a recursive nightmare thats different for

each language.

Closer to english keyboard for english users is good.

Real german support for germans is good

Spanish i know, and they dont use ¡¿ as any of the international keys, so thats possible. I understand the french type numbers

as dead-keys directly. Ctrl+alt+combo on 5 6 7 for aigu retroflex and grave is the closest hack i can think of where you dont have to remap anything.

That was the biggest 4. Its not 4/4, but its a far cry from the proposed 0.7/4. Besides, many languages work fully with 3/4 extras,

thats extra sales, no questions asked.

That being said, you get a lot further with 4 than anything else, and 4 is what we can offer, so 4 it is?
 
Last edited by a moderator:
Guys you're trying to solve an impossible problem: accommodate a myriad of international alphabets within a very small number of keys.

Top priority should be given, I think, not to break Unix stuff. And to keep stuff as close as possible to regular PC keyboards. Otherwise, switching is a nightmare.

So all ASCII keys and modifiers should be where expected, given Pyra's limitations. I think dedicated Esc is a must, and Insert is very desirable.

Other than that, I think remapping is difficult to avoid for us Latin / Scandinavian / French / German / ... users.
 
Guys you're trying to solve an impossible problem: accommodate a myriad of international alphabets within a very small number of keys.

Top priority should be given, I think, not to break Unix stuff. And to keep stuff as close as possible to regular PC keyboards. Otherwise, switching is a nightmare.

So all ASCII keys and modifiers should be where expected, given Pyra's limitations. I think dedicated Esc is a must, and Insert is very desirable.

Other than that, I think remapping is difficult to avoid for us Latin / Scandinavian / French / German / ... users.
This is why I suggested a template or stencil that would fit around the keys - and software mapping - then the same "unix-ified" programmer slanted keymat can be used for ANY language -  the template or stencil would have printed characters showing what characters various alt/shift combinations would produce

the SAME keymat for ANY language
 
</me gets a few words in edgeways>

It seems to me that since the right nub is 'more' analogue than the face buttons, it would make more sense for the right nub to be scrolling (with scroll speed related to nub position, in both axes) and for (some of) the face buttons to be mouse buttons.

Maybe the two new face buttons (between ABXY and the nub) should be insert and delete

I've been using my pandora like this for a while,and prefer it to trying to 'click' with what ammounts to a 2D potentiomter.
 
Grench: You are breaking the "no foreign letters on keyboard-rule" and it does make it more confusing. Especially to spanish people, as they

dont expect those symbols on those keys. You are also above 3 per key on the number-row.

There wasnt much debate on mousebuttons. If nubclick works thats preferred, and if not the pandora way still works.

There are ways of doing middleclick too, but thats all for trial and error, it doesnt have to do with the layout.

If the new buttoncluster-buttons are insert and delete you can have pageup ^ pagedown v home < end > that makes it really easy to use

since form follows function.
 
Last edited by a moderator:
Grench: You are breaking the "no foreign letters on keyboard-rule" and it does make it more confusing. Especially to spanish people, as they

dont expect those symbols on those keys. You are also above 3 per key on the number-row.
So what? Am I to get penalized for solving the problem by going outside artificial boundaries?

The 'no foreign letters on keyboard-rule' is highly ethnocentric and counter to the internationalized keyboard request ED started this thread with.

More than 3 per key is irrelevant in a normal + shifted + Fn + FnShifted world. Four is easy and solves a whole lot of issues.

Spanish speakers will simply be thrilled that the characters they need are there at all on this English/German oriented device.

Can you give me a mechanical, electrical or printing reason why this layout is not possible?
 
There could be a technical problem with putting 4th symbols on each key, and that has to do with the physical layout of the keyboard circuit.

The Pandora keyboard is laid out on a grid, when you press a key you don't (for the most part) activate a gpio pin specific to that key, but rather you short two pins, and the combination of which pins are shorted indicates which key was pressed. This works quite well for the most part but an important thing to note is that it has limitations on how many keys can be pressed at once. Specifically, if 3 or more keys that are laid out in a rectangular pattern on the grid are pressed together, only the first two buttons pressed are recognised. This means that if you hold down 2 keys in the same "row", all keys in the same "columns" as the two you pressed become unavailable. I have no reason to expect that the Pyra will be any different in this regard, so if there's to be any chording of modifiers on the main keyboard the keyboard matrix layout needs to be taken into consideration to avoid such issues.

For reference this is how the Pandora keyboard matrix is laid out:

Keypadmatrix.png


Is there any chance we could get a diagram of how the Pyra keyboard matrix maps to the physical position of the keys?

Theoretically, chording the modifiers on the shoulder buttons should not have the same problem because each should get its own gpio. (I would hope)

The use of sticky keys could also obviate this issue, but I for one would find it quite disconcerting to be unable to chord said modifiers.

That brings me to my next point though. Am I the only one thinking that making any of the shoulder buttons 'sticky' in any way would be very bad idea?
 

- Neelix
 
Last edited by a moderator:
A reminder here people that AltGr is Left Control and Right Alt, so any of the other possible Control and Alt combinations will be fine with the Spacebar key for whatever program needs it should we put say the Menu key on Spacebar to have a dedicated Escape key(as in my alternative v2c layout in my sig).

I'm not saying above that Escape will be moved to Menu's position, but it could be with only a minor imperceptible sacrifice.  
 
Last edited by a moderator:
This means that if you hold down 2 keys in the same "row", all keys in the same "columns" as the two you pressed become unavailable
This is a good point that I'd completely forgotten about. It doesn't preclude Grench's idea entirely, it just means deciding which keys are shift and altgr, and the corresponding "dead" combos are important.If shift and altgr are on a different row and column then only the two keys at the opposite corners on the grid become unavailable, not the entire row or column.
 
This means that if you hold down 2 keys in the same "row", all keys in the same "columns" as the two you pressed become unavailable
This is a good point that I'd completely forgotten about. It doesn't preclude Grench's idea entirely, it just means deciding which keys are shift and altgr, and the corresponding "dead" combos are important.
If shift and altgr are on a different row and column then only the two keys at the opposite corners on the grid become unavailable, not the entire row or column.
I suspect we're to the point where we'll need that electrical matrix to do substantive validation theory on any idea that comes up.

Looking through the most recent version of my layout, though - I suspect it will be OK.  Those 4 symbol keys only have plain, shift+plain, Fn+plain, Fn+shift+plain possibilities.  It doesn't make any sense to push alt+ctrl+shift+\ for example.  Those 4 symbol keys aren't where we're going to run into any serious trouble.

Consider which keys/symbols make sense to use more modifiers on.  The F1-F12 keys live as a modifier level and are in Alt-Gr positions on ALL of the keyboards.  If any key combination is going to have issues - it's them.  It is perfectly logical and legitimate for someone to need to do the following:

Shift+Alt+Ctrl+F1

As I understand that, on my keyboard that would require AltGr (Fn) to be active which is already 2 buttons chorded, so it's really:

LeftCtrl+RightCtrl+Shift+Alt+Ctrl+F1 which is, in theory, a 5-6 button press on ANY of the proposed layouts depending on how it's scored.  The only way out of THAT would be to put the F1-F12 keys on the unshifted top level - and even I don't want them there.

So, if it's really a problem, then we have MUCH bigger issues than my 4 symbol keys.

This brings up another thought though - do we REALLY have to use AltGr (LeftCtrl + RightAlt) or can we have a true Fn key that isn't consuming two of our primary modifier keys?
 
Last edited by a moderator:
Just sell the pyra with blank keys and tell users to paint it themselves if they dont like qwerty... who knows maybe have a competitive event to see who has the most creative hand painted keyboard!

Prizes could include...a production version of the winner's 'art' work ! or a packet of instant noodles... whichever has more value to the winner.
 
I just want my pyra to look pretty and to be able to do stuff. Who knew a keyboard thread would be like this.
 
A reminder here people that AltGr is Left Control and Right Alt, so any of the other possible Control and Alt combinations will be fine with the Spacebar key for whatever program needs it should we put say the Menu key on Spacebar to have a dedicated Escape key(as in my alternative v2c layout in my sig).
No. NO.

Alt-Gr is a separate key. It is not a combination key. It is only Microshat windows that lets you use ctrl-alt instead of alt-gr.
 
do we REALLY have to use AltGr (LeftCtrl + RightAlt) or can we have a true Fn key that isn't consuming two of our primary modifier keys?
What slaeshjag said. I don't know where this idea that AltGR is two modifier keys came from. On a real keyboard it is its own key and scancode.Even if not, we already know just from looking at the board that it's a single key and would be pretty stupid to wire it to any other key, so as far as the software is concerned it is a distinct key, it doesn't matter what we call it.

Call it Fn if it'll make you feel better, it does the exact same thing. ED is calling it AltGR because thats the real purpose of it: alternate graphic.
 
I type the following languages regularly on my device:

1/ French

2/ English

3/ Korean

I'd rather have a good english keyboard layout on the Pyra, very usable for terminal and computer stuff, AND a very quick/convenient/global way to switch layouts/IME.

I will never push even only 2 consecutive buttons to input é è à ù ç , ' . when typing text in french (email, office, forum post, IM, etc...). I need direct access to those. But I don't need them printed on the keyboard, if I can switch fast between the qwerty standard Pyra layout, my custom azerty, and the Korean IME, it will be perfect.

The standard layout would not show any region-specific character. I also don't like the idea to have german chars printed on the keyboard.

Could we have a button for changing layouts maybe in the top row ? Brightness change could be meta, I wouldn't mind.

Am I the only one who would prefer this approach to have 1 good layout per language instead of having 1 shitty layout trying to solve everything and satisfy nobody ?
 
Could we have a button for changing layouts maybe in the top row ? Brightness change could be meta, I wouldn't mind
Non-issue. It's pretty easy to add a shortcut that changes keyboard mappings, at least in xfce. No need to waste dedicated keys for it, nor subject everyone that wants such a feature to a single "standard", everything is already in place to allow you to pick effectively whatever shortcut you want for that.
 
Am I the only one who would prefer this approach to have 1 good layout per language instead of having 1 shitty layout trying to solve everything and satisfy nobody ?
You're missing the point. We can't have "1 good layout per language". There can only be one layout. It will of course be easy to change the layout in software, but you can't change what's on the keyboard. This argument is all about the one set of keys that will be printed on the keymat. People want to come along and change it in software there's no problem other than the keys won't necessarily line up with what it says on them.
 
Back
Top