And now for something completely different (Keyboard Option)


I noticed your signature says you're from Trondheim.  So, your ideal layout would be something like this?
http://en.wikipedia.org/wiki/QWERTY#Norwegian
 
If you activated a Norwegian 'keyboard local' in Debian Linux on a hypothetical Pyra based on my layout here:
http://www.keyboard-layout-editor.com/#/layouts/fcd69e93d9f1fdd811c8d13cc212f3a6
A few things would happen.
 
No, the characters listed on the keys would not change.
 
However, at that point the Alt key on the lower right becomes AltGr.
Type the ' key (Fn+H) and the result should be Æ.

Type AltGr + ' (AltGr+Fn+H) and the result should be Ä.

The P+3 and L+2 are preserved in my layout when put under an AltGr definition, but they certainly are not easy AND they would require the end user to have memorized the US keyboard equivalent.  It's up to the end user to decide which is better/worse, changing to a localized keyboard definition that masks the US layout with regional AltGr overlaid or to use the default (In this example mine) layout and it's functions for non-English users.

In my case this is printed German, diacritic keys for French, a few additional keys for Spanish and a compose key for anything else that doesn't otherwise 'fit'.

Unfortunately, Norwegian wasn't even on the list of priority languages.  I addressed English, German, French, Spanish, Other, in that order.  I think that it is -possible- to do Norwegian on the layout as it is, but it certainly won't be pleasant.
 
Very tired. DosBox understands key inputs. Its not hardcoded to have keycoded related from scancodes.

When you say "has to work" is that only when you choose not to have AltGr? I dont see the need for Fn.
 
comradekingu said:
Very tired. DosBox understands key inputs. Its not hardcoded to have keycoded related from scancodes.

When you say "has to work" is that only when you choose not to have AltGr? I dont see the need for Fn.
Click to expand...
In the case of my layout where top level US English keyboard standard are buried one layer down under a Fn key, IFF you have selected an AltGr regional keyboard (OS level) then in order to input an AltGr + what is normally a button at the top level but lives at the Fn level on the keyboard, you'll need AltGr+Fn+button.
 
This is the Grench proposal, simplified and slightly modified:

http://www.keyboard-layout-editor.com/#/layouts/3cc8046592f2ce4e6d11ab695b7a1035

I think it looks much better that way. It has all the US-QWERTY keys, at or very close to their expected position. The dead diacritic key almost covers all Western European languages, and there's Fn+ASDFZXCV as spare room for any missing letters like Æ Å Ø ß ç ñ. Bonus points: the next most important diacritic (caron), the first one that is not natively present, can either be mapped to Fn+V (which has the right shape), or directly to Fn+CSZ for ČŠŽ, which are the most important letters with a caron. Also, the French can map é and è to Fn+2 and Fn+7, which makes sense to AZERTY users. Fn+9 and Fn+0 are not free for ç and à, but those can be mapped to Fn+C and Fn+A, so that also makes sense.

Ctrl and Alt in the main keyboard block is of course convenient for shoulder-modifier-refusers, and it makes sense to have Ctrl on the right because many common Ctrl-shortcuts are with letters on the left (e.g. CTRL-Z,X,C,V for undo,cut,copy,paste).

What I don't like though, is that period and comma are not primary keys. This is a step backwards compared to the Pandora keyboard...

I also don't like ABCXYZ labels on the action buttons, and dedicated hardware toggle keys (while we don't even know if USB toggle is going to be "a thing": it could very well be the case that turning off USB does not save any battery power at all, and then why would you want to toggle it? Let alone sacrifice a key to it!)

It's also a bit of a pity that Fn+vowels are not free for remapping because of the F-keys. Having F1-F12 neatly in a row is nice though.

In this simplified form, I kind of like this proposal; it makes sense in many ways. In its original form though, it looks too arbitrary and cluttered to me.
 
_wb_ said:
This is the Grench proposal, simplified and slightly modified: http://www.keyboard-...d11ab695b7a1035
Click to expand...
Surely the Start and Select buttons should retain the Ctrl and Alt status? or is there no desire to be somewhat compatible with the Pandora?
Is there a blank version of the keyboard layout? I might have a go at making a layout
 
pmprog said:
_wb_ said:
This is the Grench proposal, simplified and slightly modified: http://www.keyboard-...d11ab695b7a1035
Click to expand...
Surely the Start and Select buttons should retain the Ctrl and Alt status? or is there no desire to be somewhat compatible with the Pandora?

Is there a blank version of the keyboard layout? I might have a go at making a layout
Click to expand...
Well yes, in my opinion it is better to let at least the game controller buttons be backwards-compatible with Pandora, that is, L_Alt and L_Ctrl on START and SELECT, Home/End/PgUp/PgDn on the action buttons, R_Shift on L1, R_Ctrl on R1, and of course the dpad being arrow keys.

But it's not a hard requirement; I can imagine that if we come up with a way to run Pandora PNDs, then it would be like a superficial emulator, which could remap keys if needed to regain compatibility. So if Grench likes to change things in a non-backwards-compatible way, there is no overwhelming reason why he shouldn't be allowed to do that.

If you're going to make a proposal of your own, please take a look first at the existing proposals (http://boards.openpandora.org/topic/17568-final-keyboard-layout-proposals/);/URL] perhaps there is already one that is very close to what you want, and it might make more sense to propose some tweaks (to its author), than to make a completely new proposal of your own.
 
Last edited by a moderator:
Grench said:
I noticed your signature says you're from Trondheim.  So, your ideal layout would be something like this?

http://en.wikipedia.org/wiki/QWERTY#Norwegian


If you activated a Norwegian 'keyboard local' in Debian Linux on a hypothetical Pyra based on my layout here:

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


A few things would happen.


No, the characters listed on the keys would not change.


However, at that point the Alt key on the lower right becomes AltGr.


Type the ' key (Fn+H) and the result should be Æ.

Type AltGr + ' (AltGr+Fn+H) and the result should be Ä.

The P+3 and L+2 are preserved in my layout when put under an AltGr definition, but they certainly are not easy AND they would require the end user to have memorized the US keyboard equivalent.  It's up to the end user to decide which is better/worse, changing to a localized keyboard definition that masks the US layout with regional AltGr overlaid or to use the default (In this example mine) layout and it's functions for non-English users.

In my case this is printed German, diacritic keys for French, a few additional keys for Spanish and a compose key for anything else that doesn't otherwise 'fit'.

Unfortunately, Norwegian wasn't even on the list of priority languages.  I addressed English, German, French, Spanish, Other, in that order.  I think that it is -possible- to do Norwegian on the layout as it is, but it certainly won't be pleasant.
Click to expand...
Norwegian is the exact same as German, we both need the full layout to type. (3 more buttons at the least compared to A-Z english)

I can only explain it like this, imagine if someone took away Y V and and I from your keyboard. Now if you replace that with AltGr+something, even AltGr+Y V and I, its not enough.

My german layout keyboard has 49 symbolprints, comma and dot included. My layout has 42. Granted ² ³ § ß ¦ and symbol above å and µ are useless.

What i fail to understand is why a "mobile keyboard" has to have more symbols than a real one?  Here there are 50. Different selection, but lets look into that.

Example, Shift+AltGr+questionmarkbutton is already ¿ on real keyboards, there is no reason to print it for everyone.

 

So if you take away real AltGr the need occurs, and if you take away the full layout its more problematic too.

But why do that?

Even with a a seemingly endless supply of buttons its impossible to work in all these use-cases. It will always be just a bad implementation of assumptions.

It is overfilling the limited supply of buttons we have, (with respect to a real keyboard)

For scandinavians and germans it stops at typing before you can consider anything else.
 
Last edited by a moderator:
An additional idea I came up with...

So, I was thinking, and that's not always a good thing.

A 'Normal' US standard keyboard (excluding number pad) breaks down by top level key type as:

26 letter keys qwertyuiopasdfghjklzxcvbnm

10 number keys 1234567890

12 function keys F1-F12

11 symbol keys `,./;'[]\-=

9 modifier keys capslock, Lshift, Lalt, Lctrl, Rshift, Ralt, Rctrl

5 main 'special' keys Tab, Space, Enter, Backspace, Escape

10 navigational/edit keys up, down, left, right, Insert, Delete, Home, End, PgUp, PgDn

3 system control keys PrtSc, ScrLk, Pause

That is 86 usable keys on a 'normal' US standard keyboard.  Add 2 for the mouse = 88.

The Pyra has:

4 shoulder buttons

4 'keys' in the D pad

7 keys in the center 'T'

2 'keys' by pressing the nubs

6 keys in the right game pad

45 in the 'main' section

That is 68 usable keys on a 'Pyra' (including the 2 on the nubs).

So, the Pyra starts with a 20 key deficit.  

Making an assumption here, but I believe we want to make sure that the entire US keyboard set AND includes provisions for a few non-English languages are taken into account.  The method of using Fn+Shift+key has opened up enough potential places to map things to that this IS possible.

However, we're chasing each other in circles because no matter how it's arranged, something must be compromised to do it.

I see this as a choice of a few trade-offs.

If numbers are going to live on the top level of the top row, symbol keys are going to be forced to a Fn+key and Fn+shift+key level.

We can have one or the other - numbers top level OR symbols (punctuation, etc.).

The keyboards I generated with the numbers on the Fn level caused immediate outcry.  But, which is worse?  Having numbers on the Fn level OR having symbols on the Fn level?

If we can accept that the symbol keys should take precedence over the numbers keys, something very interesting can happen.

http://www.keyboard-layout-editor.com/#/layouts/5396ee5f893d78a100dcce1859febcd0

And that right Alt key?  It should be able to be a 'real' AltGr, if the user selects a US International keyboard type.

To avoid the 'clutter', I did not put the AltGr symbols on the above layout.  It would work out like this, if the AltGr symbols were mapped to the US layout's base symbols:

http://en.wikipedia.org/wiki/AltGr_key#US-International

Note, this is a first attempt at yet another completely different layout.  It will likely require some refining and adjusting.  It is posted here as an idea for thought and discussion.  It is a prop for the question of, "What if we gave symbols precedence over the number row."

I think it shows promise.  What are your thoughts?
 
http://ergodox.org/has 72

Has 61  http://deskthority.net/wiki/60%25

http://deskthority.net/wiki/40%25 has even less, but most of the 40% only work for english.

Its not an apples to apples number with the 68 on the pyra, but we see it gets really ugly at one point, in succession new paradgimns have to be employed for each time the number is lowered too much. The pandora to the pyra is two such jumps. Not putting symbols all over the letters, and jump 2 is being able to input A-Z+3 and 4 languages with dedicated keys.

61 didnt change anything drastically, so there is hope.

My german keyboard has:

13 numberrow-keys vs 10 on the pandora (fortunately they arent all 3 per key, so they can be condenced)

35 letter-buttons. Vs     32-33 maximum for pyra (depending if you count double-space as 2) Just enough to get german and a few others in. (34 if you can do without keyboardshift, but that puts the knife a little too close to the throat in that it excludes a lot of people)

49 symbols                     42 of which are then needed.

With the ability to press shift/altGr/ctrl/alt, and even meta out of the way, and the alphabet increased to ability, its all about symbols.

It just fits with 33 and 3 per key on letters, and mostly 2 per key otherwise. It could be 3 per key on P+2 and L+2 too, but then it would get into recursive remapping if you wanted to type german.

With the extra letter buttons, you dont need ü ä ö ß and similar. Thats one way to save. Bonus.

Similarly more buttons and less modifiers means more AltGr and Shift+altGr combos. Bonus.

Not having 2 shifts and 2 ctrls is a way to save. And evidently not something that costs in terms of efficiency.

Not having meta on both shoulder and keyboard is a really great way to save, because then you enable the whole alternate graphics mode, and that solves a whole heap of problems. Its nNumber of modifiers^number of letterkeys. We see that it is exponentially more valuable to put these things in the area that isnt the restricted typewriter area. And its a symbiotic relationship.

35 on a real keyboard  33 max for pyra.  (3 or 4 less if you want to type german) ( typing ß directly you have to do without shift, but then the real number to deduct from is 34)

It also means meta is open to more possibilities. If you only deduct 12 keys from the total, thats 21 new possibilites.

0 on a real keyboard, 21 for the pyra

With shift+meta you are looking at 21 new ones. And its still possible to Shift+Fkeys.

0 on real keyboard,  21 for the pyra

If we consider just symbols, the pyra wins. It can make up for unforeseen missing things, and also do whole alphabets from some of the regions that didnt fit without having to switch anything.

AltGr should ideally be 35, but fortunately some things are duplicated on Alternate graphics and the number-row, so it pans out. Each region has a lot of useless ones too, so there is room to work here.


Requires the work to be put in for each region to be fully smooth.

 

If we let ctrl+alt be dead-key, then we also have that in a standard way. Rather than the AltGr of the US international layout, which does the same. I also like the "Real" AltGr a lot better.

It looks like there are more ways to input on a pyra, but we havent considered the ^ button.


We have to deduct one meta+button  (The P+2) to get that. The reason it cant be done with AltGr is because AltGr+^ does something already.

 

Again a few less buttons, but since you have all the important letterkeys, and all the important diactrics on number-row, i dont think anything of value is lost.

 

TL;DR To me it seems the pyra is able to input even more than a regular keyboard. 
 
Last edited by a moderator:
CK - I read that three times and still can't figure out if you like or do not like the idea I floated or are simply arguing for your keyboard layout instead...?
 
You can go where you want with it. I like the method of thinking you set forth.


 


Good artists copy, great artists steal.


There is no mine or your layout in my head. Ive done all the layouts i could think of, and ive shared the ones that were balanced. I've taken every single idea i thought was valuable and looked at what i could do with it


 


For me i arrive on the one which has the more opportunities / the least amount of expected functionality broken.


 


If you consider layouts to be the same, it makes more sense to measure them in lost or added capabilities.


 


Or you can measure them in how many people they cater to.


 


Or there could be some quality that is more important than or conflicting with the above.


 


Who do you put under the bus?


 


For me its a case of playing on the horses that all can benefit from. Less clutter, more efficiency, as easy as possible.
 
Last edited by a moderator:
It has come to my attention via the keyboard matrix that many of you don't actually understand how this keyboard works for international use and gaming.
 
Main printed layout:
http://www.keyboard-layout-editor.com/#/layouts/5396ee5f893d78a100dcce1859febcd0
 
Things that THIS layout does that few (maybe none) others do for international use:
IFF the end user activates the AltGr by selecting a, 'US International Layout' similar to these:
http://en.wikipedia.org/wiki/AltGr_key#US-International
http://www.forlang.wsu.edu/help/keyboards1.asp
THEN this becomes available:

I had to remove a lot of the extra explanatory text.  The keyboard layout editor stops being able to save past a certain number of characters.

http://www.keyboard-layout-editor.com/#/layouts/2a0d638adab6a5b607c27fc6d3af6f14

Not only P+2, but P+3 keys are available, but the +2 had to 'wrap' and move down to the bottom row.  They  are still in order and available on the top layer.  Still on the right side of the keyboard.
 
L+2 keys are available, but they had to 'wrap' and move down one row.  They are still in order and available on the top layer.  Still on the right side of the keyboard.
 
Under AltGr, all five diacritic dead keys  are are available and in their customary locations. '`~^"
Without activating AltGr, the most common diacritics can be used via the dedicated sticky diacritics dead key.  This means ALL of these can be struck WITHOUT loosing the right alt to AltGr.
ç Ç
á é í ó ú ý
Á É Í Ó Ú Ý
ä ë ï ö ü ÿ
Ä Ë Ï Ö Ü Ÿ
à è ì ò ù
À È Ì Ò Ù
â ê î ô û
 

ß could also be printed to Fn+B, but the layout editor ran out of room.

Things that THIS layout does that few (maybe none) others do for gaming use:

Fn keys AND number keys can be locked forward and used without further modifications in game.

What this means is that First Person shooters (HalfLife, etc) can use 1-5 for weapon selection AND have F1-F12 free to map to communications commands.

Neverwinter Nights (Assuming it becomes playable - which it should) would be able to map spells/actions/weapons to F1-F12, Alt+F1-Alt+F12, Ctl+F1-Ctl+F12.  With this contiguous row 'locked forward' there is no fumbling needed.

DosBox and QEMU applications should 'agree' with the symbols printed on the keyboard.  All pairs are retained.

Things that THIS layout does that few (maybe none) others do for editing use:

Symbols are all top level.  Not just, and . but all of the normal ones are there and present.  Symbols on the number keys are JUST as accessible as they are on a dedicated number row.  No kidding.  Fn+Shift are mashable and require the exact same energy and thought as Shift by itself.

Numbers don't actually suffer much by being on the 2nd layer!:

This may be hard for many of you to get past.  If you want to do single number entry, just hold the Fn button with either the left thumb or right index finger.  Inputting a long string of numbers?  Push both Fn buttons (main and shoulder) and the number row (and F1-F12 row) become 'locked' forward.  This means you can let go of Fn and type numbers and F1-F12 keys (macros anyone?) as if they were the top layer - because at that point they ARE the top layer.

By putting the numbers "one layer down" on the Fn, it opens up the keyboard for TRUE AltGr use, is BETTER for gaming use, gives writers/editors/programmers all of the symbols that they want and need on the top layer.

All of the keyboards compromise one or more things.  This keyboard makes ONE compromise, in that it moves the numbers to the Fn modifier.  BUT, it has serious gains in every other aspect as a result.
 
Last edited by a moderator:
Its the p+1 that kills it for me. I would want p+2. Nice thought though.

I think its too far removed from the expectations of a keyboard. Anything of the sort would lend itself to be an addition to the main thing, or otherwise obscure.

To me [ ] belong on the right, while < > belong on the left.
 
Last edited by a moderator:
comradekingu said:
Its the p+1 that kills it for me. I would want p+2. Nice thought though.

I think its too far removed from the expectations of a keyboard. Anything of the sort would lend itself to be an addition to the main thing, or otherwise obscure.

To me [ ] belong on the right, while < > belong on the left.
Click to expand...
You're ignoring the other factor, though. This keyboard is designed for English first. It isn't and will not be a German or Norwegian keyboard at it's roots. The closest you're going to get will be accommodations based on the US International layout.

http://en.wikipedia.org/wiki/AltGr_key#US-International

[] are on the right.

<> are on the right.

«» are on the right at AltGr + [].

Your 'true P+2' and <> on the left isn't going to happen, unless we completely abandon the English first rule and fully abandon DosBox and QEMU ease of use.

http://en.wikipedia.org/wiki/QWERTY#Norwegian

We need to start with an English keyboard and work outward to additional support. You seem to keep wanting to start with German/Norwegian support and work backward to English.
 
Last edited by a moderator:
At the risk of offending the clutter police, I have created a version of my new layout that gives the international (non-English speaking) users more without having to result to AltGr mappings.

http://www.keyboard-layout-editor.com/#/layouts/9156e2971235de513c368a4f8aa49de0

All 5 primary Diacritic Dead Keys are now accessible. Unfortunately, ~ is not AS accessible as the others, which are accessible via a roll-on mash with Fn and or shift.

Any thoughts? Better or worse?
 
In this exercise I'm exploring wider application of diacritics for wider non-English language support.

http://www.keyboard-layout-editor.com/#/layouts/6ea72dff66f737f4623eb474a9279b26

The big change here is a completely different method of handling dead key diacritics. Rather than sprinkling diacritic symbols all over the board OR having all of the accents be 'live diacritics' and requiring a space after them to get just the accent, this one uses a single sticky diacritic dead key.

On the bottom left, you will see a key marked with the dotted circle symbol: ◌

It doesn't show up quite as well in the forum's default font.

In theory, this would be the most flexible system supporting the widest breadth of languages. Unfortunately, it winds up being a bit cumbersome in application and doesn't gain anything or much over simply using compose.

To type diacritics:

Press the ◌ key and release.

Press the key that represents the accentuation you wish to apply and release.

Press the key that you want the accentuation to apply to.

Alternatively, the 11 most common diacritics could be driven via direct keys:

http://www.keyboard-layout-editor.com/#/layouts/2cc677f4dd18c03e172e2ac65b482160

To type diacritics, select the diacritic symbol to apply, then select the key to apply it to.

The reason for NOT making each symbol key diacritic by default is that IFF that system is engaged, to type ' would require typing the ' symbol then space.
 
Last edited by a moderator:
^ On linux, pressing it twice usually also produces the non-dead symbol. My only exception I've noticed so far is some webkit based browsers not producing anything if you just press it twice.
 
I put <> on the right btw, where i think it should have always been. Granted that level of freedom wasnt available for someone adding as time went by. On ISO layout it eats up the left shift.

It is slighly strange to argue ad populus when "english first" isnt weighed up against "numbers first" which seems to be a much more agreed concept.

Can you give your views on what you mean by english first, what one has over the other and vice versa? Is it the key-pairs only, or something more?

It would be easier trying to understand and to include what you have in mind about your choices then.

I find it slightly ironic that US layout with international AltGr has  «» at P+2
 
Last edited by a moderator:
You must log in or register to reply here.

Similar threads

ible
Keyboard culling and constraints.
Replies
1
Views
2K
FBnil
FBnil
_wb_
Final keyboard layout proposals
Replies
14
Views
12K
Grench
Grench
Grench
Comparison matrix for keyboard layout proposals
9 10 11
Replies
208
Views
26K
Grench
Grench
ible
Hoping for a keyboard vote
2
Replies
21
Views
3K
Grench
Grench
_wb_
12/11/12/11 keys per row instead of 11/12/11/12
Replies
6
Views
2K
rygD
rygD
Back
Top