It's the keyboard layout.


I am also personally slightly in favor of Meta-only, 2-labels-per-key.

It looks more as if it was meant to be like that, instead of having something that tries to imitate a full keyboard but just lacks keys. E.g. the pattern { } \ | / [ ] looks rather pleasing to me, and the - + = with / * ( ) nearby too. Also, | (or) below & (and), / (division) below * (multiplication), and the punctuation symbols ? : ; , . in a nice arc around space (these symbols are almost always followed by space, so you get some nice button-mash combos there). It looks clean.

Of course you can reverse that argument and say that the layout with Shift+Meta is closer to a standard full keyboard. That's mostly only true w.r.t. the symbol shift-symbol pairings, not really w.r.t. the symbol locations: in both of these proposals, the symbols are roughly near their 'normal' position, but not at their normal position (we would need at least two more keys on every row for that) or even at a consistent offset from their normal position (e.g. all on the correct row and 3 positions more to the left than normal).

So given that a full keyboard layout is impossible anyway (not enough keys), it makes sense to follow US-QWERTY for the keys we have (letters, numbers, two or three punctuation symbols), while doing something that makes more sense for the 'missing' keys. In particular, -_ and =+ are weird pairs in US-QWERTY, making - = primary symbols and _+ shift symbols. Having + and - on the same level makes much more sense, and underscore doesn't really belong there at all: underscore is not used in arithmetic, unlike * ( ) - = +. Also three out of four basic arithmetic operators * - + are on that top row, while division / is quite far away. Minus and division are primary symbols (of course that's because they are also dash and slash), while the more important plus and multiplication are shift symbols. And so on.

We just have to make sure that DOSBox etc are properly ported/configured such that if you press ':' on the Pyra, then it produces a ':' in the emulated DOS. This can be done.
 
...except it has compose and _ both on meta+space.  :lol:

In any case I'm still in favour of the meta+shift version myself.

If I might suggest an adjustment to that meta+shift layout  I'd suggest taking a cue from the US-International layout and placing ß and § on meta+S and meta+shift+S respectively.    That would free up meta+T for something else.  (eg œ)

- Neelix
 
We just have to make sure that DOSBox etc are properly ported/configured such that if you press ':' on the Pyra, then it produces a ':' in the emulated DOS. This can be done.
heretic! burn the blasphemer !

I was beginning to think I was the only one to think that one piece of software should be fixed, instead of bodging hardware to work with it and making every other user/piece of software suffer...  
 
It's not really just one piece of software though,  it's any number of other programs designed the same way, it's just that DosBox is the most prominent example.  

In any case,  since shift+meta is required for uppercase versions of the letters  on the meta layer anyway I see no reason to shy away from using it for symbols to provide more real estate for inclusion of other symbols.

- Neelix
 
...except it has compose and _ both on meta+space.  :lol:
Oops. Fixed: http://www.keyboard-layout-editor.com/#/layouts/ad7f8862d430184105b3d91f7d717c5a

It's not really just one piece of software though,  it's any number of other programs designed the same way, it's just that DosBox is the most prominent example.  

In any case,  since shift+meta is required for uppercase versions of the letters  on the meta layer anyway I see no reason to shy away from using it for symbols to provide more real estate for inclusion of other symbols.
OK, if that's the motivation. We can probably cover all Latin-script languages with the available real estate. But no complaining about "clutter" then! ;)
 
It's not really just one piece of software though, it's any number of other programs designed the same way, it's just that DosBox is the most prominent example.
I believe QEMU was properly ported and I can't think of any other's that might have this issue ?
 
Last edited by a moderator:
Slightly tweaked proposals:

Meta+Shift: http://www.keyboard-layout-editor.com/#/layouts/59bae967ccc523e5475e267687fd95d2

Meta only: http://www.keyboard-layout-editor.com/#/layouts/448795011aec0eda1781efb5cd9ea44f

I tweaked the dead diacritics a bit:

If ü ö ä are available precomposed, then Meta+" can be used for both the remaining umlauts (ë ï) and the Hungarumlaut (double acute) ő ű. Win! Hungarian is covered without any further changes!

I now understand that the Polish Ł is not really an L with a stroke, but the diacritic is called a kreska and it's the same one as on their letters ćńśź. Basically it's an acute accent for consonants (and in the case of L, the acute/kreska goes through the letter instead of on top of it). So Meta+' can produce all of áéíóú ćńśźł, and that makes sense. So Polish can be covered with just the dead kreska (Meta+'), dead ogonek (Meta+,) and dead kropka (Meta+.) -- woohoo!

Similarly, Czech/Slovak can be covered with just the dead háček (Meta+<), dead acute (Meta+'), and dead ring (Meta+.) for ů.

So some major Eastern European languages can be covered, in particular the countries close to Germany.

Meta+> is a dead ^, and in a LaTeX sense (and in a Compose combo sense) it feels natural to let it act as a "dead superscript key" when used with numbers instead of vowels. So it could produce the ² ³ you find on German keyboards (and the ¹ found on some others, and ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ⁰  too for that matter).

If have superscripts, why not subscripts, for writing things like H₂O and indices on variables (x₃ - x₁₅) in plain Unicode. I would put it at Meta+, (together with the cedilla, since that is a rather subscript kind of diacritic), but it could also be on Meta+< for symmetry and Shift+_ for LaTeX/Compose key compatibility. AFAIK no standard keyboards have ₁ ₂ ₃ ₄ ₅ ₆ ₇ ₈ ₉ ₀, but why not add it.

I'll volunteer to help write the default xkb configuration file for the Pyra ;)

In a layout that does not have Shift+Meta labels, Shift+minus could act as a dead macron (āēīōū), Shift+/ could act as a dead stroke (ØĐŁĦ), and more like that for the remaining obscure diacritics.
 
Is it me that this has more to do with the mapping than with the layout of the keys?

Like in windows being able to use the same keyboard in US international or in Dutch mode wich give slightly different handeling of ëö¿øöµ° type characters. However the layout of the keyboard does not change.

Maybe it's nice to have a layout consensus and worry about the underlying special characters when the layout is fixed. 
 
Last edited by a moderator:
Is it me that this has more to do with the mapping than with the layout of the keys?

Like in windows being able to use the same keyboard in US international or in Dutch mode wich give slightly different handeling of ëö¿øöµ° type characters. However the layout of the keyboard does not change.

Maybe it's nice to have a layout consensus and worry about the underlying special characters when the layout is fixed. 
To be clear: I am proposing to actually print those special characters (üöä etc) on the keys.
 
Is it me that this has more to do with the mapping than with the layout of the keys?

Like in windows being able to use the same keyboard in US international or in Dutch mode wich give slightly different handeling of ëö¿øöµ° type characters. However the layout of the keyboard does not change.

Maybe it's nice to have a layout consensus and worry about the underlying special characters when the layout is fixed. 
To be clear: I am proposing to actually print those special characters (üöä etc) on the keys.
Hmm I regularly use the ° and the µ but have no need to see them next to the "m" and the ":" . were you also planning on printing the capital letters next to the small ones ;)  
 
I think we are confused about the distinction between compromise, and compromised.

The international users do not want a A-Z only keyboard. The only bigger group, English, doesn't need to be plagued with foreign stuff.

These two go hand in hand, resulting in a good compromise. Exclusion is not the same as compromise, it is the opposite.

The distinction between what some people prefer isn't important, not excluding huge groups or disadvantaging them is.
 
I believe QEMU was properly ported and I can't think of any other's that might have this issue ?
Just because you can't think of any doesn't mean there aren't others...  Oolite was another one that ptitseb had to fix.  

OK, if that's the motivation. We can probably cover all Latin-script languages with the available real estate. But no complaining about "clutter" then! ;)
Ahhh,  but I was never really worried about clutter. :)     That said, clutter doesn't have to be a problem and that's where the difference between mapping symbols and printing them comes in.    I think you are on the right track with the meta+shift layout above,   but I think that only the symbols you would normally find on a US keyboard and the diacritics need to be printed,  and an onscreen keymap could show the positions of the rest.  You could even make the default key map part of the default desktop wallpaper. :)   

- Neelix
 
OK, if that's the motivation. We can probably cover all Latin-script languages with the available real estate. But no complaining about "clutter" then!
This is what I've been saying for a while now, why I became so keen on Grench's idea. Forget DosBox compatibility, it frees up space and helps with mental mapping.Regarding clutter, I've never believed that three symbols was cluttered and have yet to see anyone present evidence that it is. It's been proven that we can get quite a few characters by only using 3 symbols per key with implicit upper/lowercase letters.
 
OK, if that's the motivation. We can probably cover all Latin-script languages with the available real estate. But no complaining about "clutter" then!
This is what I've been saying for a while now, why I became so keen on Grench's idea. Forget DosBox compatibility, it frees up space and helps with mental mapping.Regarding clutter, I've never believed that three symbols was cluttered and have yet to see anyone present evidence that it is. It's been proven that we can get quite a few characters by only using 3 symbols per key with implicit upper/lowercase letters.
Agreed. The clutter police thing is far overblown. It may have been relevant on early layouts with 4 characters presented on each key, but we've progressed a LONG ways since then.

_wb_'s layout above and this one are very similar with some distinct differences. Is this still on track or have I deviated too far from the layout that you liked?

http://www.keyboard-layout-editor.com/#/layouts/467f092b9169fe6c6b411baa5a39beeb
 
OK, if that's the motivation. We can probably cover all Latin-script languages with the available real estate. But no complaining about "clutter" then!
This is what I've been saying for a while now, why I became so keen on Grench's idea. Forget DosBox compatibility, it frees up space and helps with mental mapping.
Regarding clutter, I've never believed that three symbols was cluttered and have yet to see anyone present evidence that it is. It's been proven that we can get quite a few characters by only using 3 symbols per key with implicit upper/lowercase letters.
Agreed. The clutter police thing is far overblown. It may have been relevant on early layouts with 4 characters presented on each key, but we've progressed a LONG ways since then.


_wb_'s layout above and this one are very similar with some distinct differences. Is this still on track or have I deviated too far from the layout that you liked?

http://www.keyboard-layout-editor.com/#/layouts/467f092b9169fe6c6b411baa5a39beeb
The dead stroke and double-acute on Meta+A is more or less redundant: as I discovered earlier today, if we have üö already precomposed, then the Meta+" can act as double-acute for the Hungarian űő, and the stroke in Ł is actually a Polish acute (kreska) so we can let it be produced by Meta+' L. So there is no more need for double-acute, and stroke is only useful for Đ and Ħ, but those are relatively obscure.

Dedicated primary PrintScreen and Pause feels like a bit of a waste, and why no more primary Esc?

I prefer a dedicated primary Tab.

F11 and F12 up top feels more 'correct' than down below, though a mashable F11 to toggle fullscreen is quite nice.
 
Last edited by a moderator:
Besides one of my own ( ;) )I like sabres latest the best...

:ph34r:
I'm partial to the latest as well because I know it will work. :)   

Anyone know which is the true favored layout now from the compromises team? Lost after so many revisions from them.  :huh:
 
Last edited by a moderator:
I like the progress, and I have a feeling ED wants only one meta label per key. (It would be nice to know his preferences, but on the other hand he didn't ask us to work on this either...)

My comments/concerns with _wb_'s latest and greatest:

http://www.keyboard-layout-editor.com/#/layouts/448795011aec0eda1781efb5cd9ea44f

1. I like the symmetry between {}[]/|\. To me it really helps guide the eyes towards the symbols. In my own layouts I also try to have patterns, though I have also been trying to keep things like ü on Meta+U.

2. I appreciate the "breakthroughs" on diacritics. I think we can all benefit from them, especially if we get the Neelix(?)-suggested keyboard Mea+GUI popup going.

3. At one point I thought about switching = and +, so there's a symmetry of (-=+). I think it's a net gain for the code-combos score. (It lowers i++, but gains -= and increases /=.) Here's an alternative rearrangement of yours which increases the code combos quite a bit, though it may look a little less symmetric to some:

http://www.keyboard-layout-editor.com/#/layouts/73a832d97d3d555a888dee767649badb

(Nice subtle symmetries: operator opposites are vertically two keys apart.)

4. Concern: I would prefer keyboard Meta and Shift to be on the right (switching places with , and .), for the following reasons. This has a nice symmetry of putting all diacritics on the left side of the board. It also makes it possible to easily do a shift+meta+button for any key on the left side of the keyboard, which would be the more common side of the keyboard to do both modifiers on. (Like with Shift+Meta+Tab for Grave, and Shift+Meta+F for Ä.) It would also raise the code combo score (you get <= and >= for free).

5. Very small concern: { Enter is a very painful code-combo, so you penalize C/C++ peeps ;) .

Any thoughts on an even more ible-fied arrangement of your symbols?

http://www.keyboard-layout-editor.com/#/layouts/1417479de73c9231d7e258fd0eb779a4
 
Last edited by a moderator:
Back
Top