Testing alternative Layouts that require single-width space. INTL layout vs Big Space, and other key

I want to test more layouts (for example INTL-layout) which require space to be single-width?


  • Total voters
    42

I'm not sure that centering really adds any comfort at all. On a regular keyboard, your hands are centered around F and J, which means the actual center is between G and H. In Saber's layout the center is on G while in my/comradekingu's layout, the center is on H. Both are non-centered by half a key.


But even if you insist that G is supposed to be the center and not B like on a normal keyboard (which is impossible in our layout since the row containing B has an even number of keys), then I don't think it makes much of a difference. It is a thumb keyboard, not a finger keyboard. The center is not particularly better than the edges. In fact, the center is probably worse than the edges. Compare the dpad and action buttons with the START/SELECT/PYRA buttons in case you have doubts about that.
I don't insist or seek to force compliance with what we're talking about. I do sympathize with our non-English members here but I also think remapping, for the handful who need to, a few keys to the German umlauts and using the Compose key is more than a fair compromise.
A fair compromise between what? I just countered the whole "centering is more comfortable" argument, so what advantages do you still see in centering? A better spot for Tab?

It just doesn't sit well to use a hardware key all the way up top(or to rely on a shoulder button) for the main modifier Fn/Sym/Meta. I do like how you have F1-F12 though. :)


Shoulder buttons are the best method for modifiers. But I agree that my previous proposal has its 3rd modifier in a weird place.


How about this:


http://www.keyboard-layout-editor.com/#/layouts/4d08add55a6c406c28b9ece1b774ee61


As far as Linux is concerned, the Pyra button and the Pyra shoulder button are Left and Right Hyper or Meta (whichever gets least in the way of existing things, probably Hyper).


There's also a Super key (this is the Windows key on a normal PC keyboard or the command key (⌘) on Apple keyboards in the top left corner for those who want the extra modifier, and a Menu key right next to it.
 
Russian (phonetic) uses only P+2:

Keyboard_layout_ru_fonetic.png
I live in Russia and I have never ever seen a keyboard with such a layout, nor anybody using it. Also it does not include 5 letters.

What does that mean: russian layout requires P+2, L+2, M+2 at minimum. At least with remapping, but of course it's preferable to have usual keys in those places.

Meta VS Hyper VS Duper
Whatever, just make sure it does not conflict with both various software and external keyboards. Best bet to use something (Hyper etc) that no software in modern use expects by default and keyboards don't even have. It would be miserable to remap stuff just to make external keyboard work right (looking at Pandora here, with completely messed mappings).
The Pyra key needs to function the same way the Pandora key, the Super key, and the Windows key do.
If so, don't set up any special input mappings with it, since Super is included in a lot of default key combinations (for example, in window managers).
I know I don't own a USB keyboard with a hyper key, so that makes anything using it potentially inaccessible if not using the Pyra's keyboard and buttons without additional steps (which I currently don't know).
It only nobody wanted to twist usual layout like hell, external keyboards could just have their usual way to input things "missing" on Pyra's mini keyboard without special modifier. Like, with any other computer? Also some of duplicated modifier keys (Alt, Super) can be remapped to new one.
 
Saber: For fun, try pressing a five-key combo every time you want to type "f" or "c" (six for caps) in english. Those letters are about the same frequency in english as ä is in finnish. (EDIT: try this on a thumb keyboard for added effect)

Compose key is only good for really rare cases, like when you're typing a quote in foreign language. It's not a solution for anyone typing in the language for more than a sentence or two at a time.


Some want alternate layouts to fix this. I'll probably map some key as an extra modifier like hyper or try to find some suitable unmapped combinations from the existing modifiers.
In my version 1 layout, non-English ä is simply Sym + a. That's at my count two key presses which isn't too bad from how your example is from how it was done on the Pandora. If this is how your Finnish keyboard is normally arranged, you'd only have to remap å to ü on my layout, or hit Compose once then letters o then a. If you have others(probably) to remap, there are placeholders ß, °, µ.

Like I asked before, is it really worth it to shuffle the Tab key, which is normally on the upper left side of a keyboard, and a few others like Escape?

Honestly, whatever the majority here wants to do with the layout is fine by me. ;)
 
Saber: For fun, try pressing a five-key combo every time you want to type "f" or "c" (six for caps) in english. Those letters are about the same frequency in english as ä is in finnish. (EDIT: try this on a thumb keyboard for added effect)

Compose key is only good for really rare cases, like when you're typing a quote in foreign language. It's not a solution for anyone typing in the language for more than a sentence or two at a time.


Some want alternate layouts to fix this. I'll probably map some key as an extra modifier like hyper or try to find some suitable unmapped combinations from the existing modifiers.

I just want to quote this for truth, and to clarify again what ComradeKingu wrote above. For many languages that have "accented" letters in them, those letters are not "an original letter modified by an accent" (which is what compose is set up to do) - They are independent letters in and of themselves. For me, being swedish, å and ä has nothing whatsoever to do with a, and ö certainly is no "modified" o. From a swedish usage perspective it would be better to skip q, w and z on the keyboard (actually, if we go by usage, 'ö' is more important in swedish than q, w, x, y, z, b, c and  j). Now, I do not propose removing q in favour of ö (visual familiarity is a good thing), but saying "a foreigner could use compose" is quite, quite wrong.

At the moment, on the pandora, I use fn-combination thanks to Slaeshjags xmodmap-file, and that is an acceptable solution - a double-press for the swedish letter. A five-press would be unusable.
 
If so, don't set up any special input mappings with it, since Super is included in a lot of default key combinations (for example, in window managers).
This is part of what I was talking about.  On many keyboards, and I think the Pandora, the super key has the logo.  What I was saying is to keep the Pyra key as the super key instead of meta/hyper/whatever, not to keep it from being a modifier at all.

It only nobody wanted to twist usual layout like hell, external keyboards could just have their usual way to input things "missing" on Pyra's mini keyboard without special modifier. Like, with any other computer? Also some of duplicated modifier keys (Alt, Super) can be remapped to new one.
I am having trouble understanding this.  What I am hoping to avoid is setting up the Pyra keyboard in such a way that an external keyboard connected to the dock will not be usable.  If a key that is not on an external keyboard is often used you will be unable to do that key combination.  Basically the opposite of the current problem trying to be fixed.  I don't know if this will be a problem, but don't break other stuff in an attempt to get the onboard keyboard to work.
 
Last edited by a moderator:
It confuses me why you modify the binding of '<' and '>' from shifted ',' and '.' to Meta-X and Meta-C.It is not more keypresses to swap that around and any application that assumes that '<' is Shift ',' and that '>' equals shift '.' might become problematic.

I would swap them around, keep base keys and their shifted values paired as much as possible.

Similarly I would not swap around | and \ either. The regular keypress should be \ the shifted one |

Like this.

<edit>Though I personally would prefer it more like this layout.</edit>
 
Last edited by a moderator:
@pndrsky: I hope my layout proposal (http://www.keyboard-layout-editor.com/#/layouts/4d08add55a6c406c28b9ece1b774ee61) works well for a Russian keyboard layout. You would probably put the period and comma (. ,) on Pyra+Space and Enter on the right shift. The  | \ / ? and Tab keys would move to Meta instead of being primary keys, and you would probably put Ë on Meta-1 or something, but other than that not much else has to move to fit in the 33 Cyrillic letters of the Russian keyboard.

If so, don't set up any special input mappings with it, since Super is included in a lot of default key combinations (for example, in window managers).
This is part of what I was talking about.  On many keyboards, and I think the Pandora, the super key has the logo.  What I was saying is to keep the Pyra key as the super key instead of meta/hyper/whatever, not to keep it from being a modifier at all.
But it's better to make the modifier that we need to compensate for the lack of keys, a different one than Super. Otherwise strange things will happen when you plug in a standard keyboard: [Windows key]+Q will be indistinguishable from F1, and so on. Also you cannot have Super-shortcuts because something like Super-F1 is impossible to type on the Pyra keyboard if you already need Super just to type F1.

It has to be a modifier key (as opposed to a hardware Fn key) so it can be used as a real key in software (this is crucial if we want to put it on a shoulder button) and so it is easy to tune its behavior in software. But most applications should not be aware of the modifier key, they should still just see "F5" and not Pyra-T. Except of course games etc. that read keyboard events at a low level (key_down and key_up events).

It confuses me why you modify the binding of '<' and '>' from shifted ',' and '.' to Meta-X and Meta-C.
It is not more keypresses to swap that around and any application that assumes that '<' is Shift ',' and that '>' equals shift '.' might become problematic.

I would swap them around, keep base keys and their shifted values paired as much as possible.

Similarly I would not swap around | and \ either. The regular keypress should be \ the shifted one |

Like this.
Yes, that is also a perfectly fine option. That would be closer to a standard QWERTY keyboard layout. My proposal deviates from that in a way that in my opinion makes more sense: bracket-like things together (<>[]{}) and punctuation-like things together ( ,.;; ), observing that shift+, = ; and shift+. = : make sense (as comradekingu remarked).

I swapped \ and | because backslash is arguably less important than pipe: the only uses I know for backslash are escape sequences in shells and printf-like strings, LaTeX macros, and paths in MS-DOS descendants. Pipe is useful for unix pipelining and bitwise/logical 'or'.

But maybe the difference in importance is not big enough to justify that deviation.

So keeping the change that does make sense (; : as shift , .) and undoing the change that makes not so much sense (swapping \ and |), this is my current proposal:

http://www.keyboard-layout-editor.com/#/layouts/28d2a90318ea9c944f7883cc8a5f8dd1
 
Last edited by a moderator:
Yes, that is also a perfectly fine option. That would be closer to a standard QWERTY keyboard layout. My proposal deviates from that in a way that in my opinion makes more sense: bracket-like things together (<>[]{}) and punctuation-like things together ( ,.;; ), observing that shift+, = ; and shift+. = : make sense (as comradekingu remarked).
Oh yes, the grouping makes some sense. I am just worried that such deviations will lead to very odd behaviour in applications that manage their own keymap (similar issues like dosbox has on the Pandora).
 
If they manage their own keymap, there are at least two out of these six: ,.<>;: that will not work out of the box anyway, but you're right, in my proposal four out of six will not work out of the box. Things will have to be adapted anyway. I suppose it should be possible to do some automatic conversion at a sufficiently low level to create a kind of "PC compatibility mode", where applications see Pyra+Q as if it were a genuine F1 keypress, and Pyra+X ("<" in my proposal) gets converted to a simulated Shift+, and so on. Such an automatic compatibility mode would be useful anyway, regardless of the layout proposal.
 
If they manage their own keymap, there are at least two out of these six: ,.<>;: that will not work out of the box anyway
You are right, it cannot be avoided altogether. My metric is, and always has been, getting as close to Qwerty as possible. It is true that this may not be optimal for everyone.
E.g. I prefer a centered P+1,L+1 layout myself, but since that hurts the majority of non-US keyboard layouts it is a bit egoistic to demand one. I would if I was convinced that would get me one though ;)
 
Updated again. This time there are two versions, one with fewer changes and the other a more radical approach.

Version 1

Version 2

The detailed explanation for both can be found here.
I like the one with Esc on Tab.

Really nice one :) .
The problem with not having two keys to the right of P and L, is that non-English speakers cannot comfortably remap those keys to the ones they need.

The layout Saber (and nearly everyone else at first) proposes is nice for English, but not so nice for non-English.

Keeping P+2 (at least P+1) and L+2 (and preferably also M+2) available for remapping is really quite important.

Examples of keyboard layouts that use P+1 and L+2:

German:

640px-KB_Germany.svg.png


Also it is better to keep the number row free of third-level modifiers, because layouts like French and Czech/Slovak use shift for numbers, primary key for accented letters, and they could use the third-level modifier to get back !@#$%^&*(). French also needs P+1 and L+1.

(Vietnamese uses the number row for accented letters and dead key diacritics, and they use AltGr for numbers and Shift+AltGr for symbols).

TL;DR : Not everyone wants to type only English. For non-English, it is crucial to have Q and A as the left-most key of their row, so there is enough room at the right to map all the keys of extended QWERT* keyboards.
I see this different.

I don't think it's important that people can remap the keys.

Why?

In my opinion only a few people would remap the keys but leave the old keymap.

Having different symbols than letters is not the preferred solution I think.

Let's take German as it's my language.

If I'm rights it's your concern that öäü aren't placed on the right position.

That's really unimportant for me.

They are not frequent letters and having them on an Fn key is fine.

They should not be on a main position anyways. Other symbols are far more important.

You know a German Keyboard is important for me.

I did cut my keymat and made a qwertz Keyboard for my Pandora.

I would never have remapped z and y if I wouldn't have swapped hardware buttons as well.

For me a good English layout should be the main concern.

If you want it international then make 4 empty Fn combinations everyone can map on his own.

Are those extra symbols really that important to give people the possibility to map them on a primary position.

My answer is no.
 
Last edited by a moderator:
I wouldn't remap P+2 and L+2 myself either, but I know there are at least some people who would, even if that means the labels and keys do not correspond anymore.

The point is: what do we lose by having P+2, L+2, M+2 available and , . in their normal spot? Even if nobody would remap keys?

Is there really an advantage to centered Q-P besides having Tab in its usual spot?

In German, 0.65% of the typed letters are Ü. Compare: J (0.24%), Y (0.05%), X (0.05%), Q (0.02%). So you have to press Ü about 30 times for every time you press Q, and about 12 times for each X and Y. You can say they are not frequent but some people will disagree.

In French, É is more frequent than V, H, G, F, B, Q, J, X, Z, Y, K and W. Also À, È, and Ê are each still more frequent than Z, Y, K and W.

In Swedish, Å and Ö are more frequent than B, J, Y, X, Z and Q.

In Norwegian, Å and Ø are more frequent than Y, C, W, Z, X and Q.

In Finnish, Ä is more frequent than K, U, M, H, V, R, J, P, Y, D, G, C, B, F, W, Z, X and Q. More than 5% of the letters in Finnish are Ä.

In Danish, Å, Ø and Æ are more frequent than J, Y, C, W, X, Z and Q.

In Polish, Ł is more frequent than J, L, U, B, G, H and its alphabet does not have Q, V and X.

In Portuguese, Ã, É, Á, Ç and Ê are each more frequent than J, X, K, W, and Y.

In Turkish, Ü and Ş are more common than G, Z, H, C, P, F and J. Even Ç, Ǧ, and Ö are more common in Turkish than F and J, and the letters Q, W, X are not even in their alphabet.

In Estonian, Ä, Õ, Ü and Ö are more common than F, Z, Q. The letters C, W, X are not in their alphabet.

In English, X, Q and Z are by far the least frequent keys.

So if you really want to get rid of keys, don't remove P+2 and L+2, but remove Q, Z and X :)
 
The point is: what do we lose by having P+2, L+2, M+2 available and , . in their normal spot?
Symetrie.

And that's really important for me.

For me every key on the Fn buttons is easy to reach.

öäü on Pandora are hard to type as you have to do a painful long button combination.

And event that's not impossible. I do it quite often while typing.

3-4 "free" Fn Keys are much more important I think.

The most important thing for me is to keep the symmetry of the Pandora Keyboard.

And there's an other thing to consider:

There are quite important characters on the buttons according to your layout: [] for example.

Ok, people might sacrifice the pound or yen on Pandora but not the [],

Did you think of that?

If you want these keys to be remap able you should place the most unimportant keys on them.

But on main position there should be the most important keys.

If you want a special layout I think printing a new keymap is the way to go.
 
Look at where J and K is on UK layout.  3  ←  J   K  → 2

And it isn't any better on German layout  3  ← J   K   → 4

Printing a new keymap does not change the fact we have 64 keys. [] is 100% irrelevant when you are inputting language, just as öäü is irrelevant for coding.

Remember you can switch between the two.  You select your layout on boot, and you are free to switch back and forth at any time with the language applet.

All we have to do is make one xkbmap file that makes sense for each language. And that isnt so hard once you have +4, once you dont it doesnt make any sense, because then the +4 isnt in the +4 positions anymore.

We cant print totally unimporant stuff on +4 like "§" because that is exactly the same as wasting keys. Also, it doesn't adhere to US/UK layout.

Printing a coding cluster on the full part of a reduced keyboard means we get a good compromise, because the pandora users are often coding people.

Consider http://www.keyboard-layout-editor.com/#/layouts/4292e8be3a23087c12ec70c2b446044c for symmetry, even the colours add up.

Changes: 

Shift is left shoulder because the imprint is to the left on the key. Meta and AltGR is to the right, because the imprint is to the right on those keys.

Everything is centered, which means it all makes sense, except Q-P on the qwerty-row should be centered on the key (not possible while F-numbering is small in the editor)

http://www.keyboard-layout-editor.com/#/layouts/69d1faa1862cce40de0c5d106c63d883 has some touchup and a note added
 
Last edited by a moderator:
So if you really want to get rid of keys, don't remove P+2 and L+2, but remove Q, Z and X :)
I am sure that you create everything correctly the first time, but I find myself hitting C-z rather often :)
Yep, and emulating many of the 8-bits, Z and X are often used for left and right ;)

FWIW, I wouldn't mind having Q on Fn+W or what have you, though I would suggest that not even having the basic QWERTY layout would suggest we've had to make big compromises. Which, judging by the opinions in this thread, some people will have to make, but still.


Seeing as emulation is still a significant use case for these devices, out of interest, were there keyboard variants for 8-and-16 bit computers sold in, say Germany, where I understand home computers outsold consoles throughout the 80s. Given the C64 (and oddly, BBC micro) had US-style keyboards in the UK, perhaps that's asking too much.


As a (UK) shell user, I do find pipe (|) hard to find when blind typing, whereas backslash (\) is relatively easy. But they're both equally important - I use backslash quite a lot for escaping spaces and other characters when I'm transferring podcasts to the system and mangling m3u files and so on. I'd say I use backslash slightly more than pipe, but there's not much in it.


Also, someone was asking earlier what backtick (`) was for - it's for subshell expansion in most shells and perl. Not one I use very often though, judging by how long it took me to find it on this keyboard.
 
Saber: For fun, try pressing a five-key combo every time you want to type "f" or "c" (six for caps) in english. Those letters are about the same frequency in english as ä is in finnish. (EDIT: try this on a thumb keyboard for added effect)

Compose key is only good for really rare cases, like when you're typing a quote in foreign language. It's not a solution for anyone typing in the language for more than a sentence or two at a time.


Some want alternate layouts to fix this. I'll probably map some key as an extra modifier like hyper or try to find some suitable unmapped combinations from the existing modifiers.

I just want to quote this for truth, and to clarify again what ComradeKingu wrote above. For many languages that have "accented" letters in them, those letters are not "an original letter modified by an accent" (which is what compose is set up to do) - They are independent letters in and of themselves. For me, being swedish, å and ä has nothing whatsoever to do with a, and ö certainly is no "modified" o. From a swedish usage perspective it would be better to skip q, w and z on the keyboard (actually, if we go by usage, 'ö' is more important in swedish than q, w, x, y, z, b, c and  j). Now, I do not propose removing q in favour of ö (visual familiarity is a good thing), but saying "a foreigner could use compose" is quite, quite wrong.
I don't think anyone here doubts the å and ä's distinctiveness Moxie. When I mentioned Compose, it was as another option for you and B-Zar and not meant to trivialize.

What I did say is that If we go by my Version 1 layout, å could be remapped to Sym + u(displacing the ü character already there). This is one way to tackle this issue. The other was the Compose method with my layout which is supremely easier to initiate since the Compose key is now a dedicated key. To put it where I did was intentional. I doubt I'll ever need the key but others might find it helpful.

Now, because I do take the circumstance of my wrought layout on some of you here seriously, I've worked on another left-centric layout which I'll be posting sometime tomorrow. Surprisingly, I didn't think it would come out as well as it did but I have to say it's not too bad a result. :)    
 
Last edited by a moderator:
There is no alternative to inputting a full alphabet, its a full keyboard or try again. As such, there is no issue created.

The issue is the reduced layout, secondarily the issue is not being able to input ü in a standard way for those who don't have it as their +4's.

Having a compose button in a non-standard position is another ugly hack you end up pulling to facilitate having a reduced layout. At which point you are using 1 out of 4 to _not get you anywhere_.

The ones who need dedicated compose, have it as P+2.

Accent grave (à, è, etc), type ` (to the left of 1) then the vowel.
Accent aigu (é), click AltGr and e at the same time.
Cédille (ç), click AltGr and c at the same time.
Circonflexe (ê), click AltGr and ^ at the same time, then the vowel.
Tréma (ö) click AltGr and " at the same time, then the vowel.

Thats how french people input french on a UK keyboard, now if you dont use all, you will have learnt your regional way of doing it, which is different each time.

There are a whole bunch of them here http://french.about.com/od/writing/ss/typeaccents_2.htm  and trying to facilitate these half-assed things never works, nor are we going to succeed in establishing a unified way to do it for all people.

Another reason why if you remove AltGr, you are running into problems.
 
Last edited by a moderator:
Back
Top