Agree with Eight Bit and Comradekingu here about too many languages incorporated being too many languages in general. If French and Dutch are the gold standard to go by then Acute, Grave, Circumflex are the epitome of a functional dead key diacritic base. Many "foreign" Pyra users will need these three. Umlauts for all too obvious reasons as well. Rounding it out are letters for Å, Æ, Ç, Ñ, and a few others.
Sometimes the painting is more beautiful when you don't dip your brush into every color.
Dutch and French need ë and ï probably more frequently than ü ä ö, so a dead umlaut is more useful to them than dedicated üäö keys.
Tilde as a diacritic is useful for ã and õ in Portuguese (and ñ if it is not already available).
Å and Æ are not that useful, they're only really used in Scandinavian languages.
With just acute, grave, umlaut, circumflex, tilde, caron/breve, cedilla/ogonek/comma, ring/dot and stroke (9 diacritic keys) you can in principle cover everything (except Æ Œ), but of course it's more convenient to have some of them as precomposed letters.
Agree with Eight Bit and Comradekingu here about too many languages incorporated being too many languages in general. If French and Dutch are the gold standard to go by then Acute, Grave, Circumflex are the epitome of a functional dead key diacritic base. Many "foreign" Pyra users will need these three. Umlauts for all too obvious reasons as well. Rounding it out are letters for Å, Æ, Ç, Ñ, and a few others.
Sometimes the painting is more beautiful when you don't dip your brush into every color.
Dutch and French need ë and ï probably more frequently than ü ä ö, so a dead umlaut is more useful to them than dedicated üäö keys.
Tilde as a diacritic is useful for ã and õ in Portuguese (and ñ if it is not already available).
Å and Æ are not that useful, they're only really used in Scandinavian languages.
With just acute, grave, umlaut, circumflex, tilde, caron/breve, cedilla/ogonek/comma, ring/dot and stroke (9 diacritic keys) you can in principle cover everything (except Æ Œ), but of course it's more convenient to have some of them as precomposed letters.
Agree with Eight Bit and Comradekingu here about too many languages incorporated being too many languages in general. If French and Dutch are the gold standard to go by then Acute, Grave, Circumflex are the epitome of a functional dead key diacritic base. Many "foreign" Pyra users will need these three. Umlauts for all too obvious reasons as well. Rounding it out are letters for Å, Æ, Ç, Ñ, and a few others.
Sometimes the painting is more beautiful when you don't dip your brush into every color.
Dutch and French need ë and ï probably more frequently than ü ä ö, so a dead umlaut is more useful to them than dedicated üäö keys.
Tilde as a diacritic is useful for ã and õ in Portuguese (and ñ if it is not already available).
Å and Æ are not that useful, they're only really used in Scandinavian languages.
With just acute, grave, umlaut, circumflex, tilde, caron/breve, cedilla/ogonek/comma, ring/dot and stroke (9 diacritic keys) you can in principle cover everything (except Æ Œ), but of course it's more convenient to have some of them as precomposed letters.
Yes, that one has all diacritics, even the Hungarian double acutes (the tenth one I forgot).
Besides the « » (which could easily be changed to Ins/Del), I also prefer to have Tab as a dedicated key.
Shoulder Shift/Meta on the right is OK for me, but I don't really see the advantage, and on the Pandora Shift and Ctrl are L1 and R1.
I wouldn't label the Compose key, because of two reasons:
- it is something that can easily be modified: if you plan to use it a lot, you probably want it on a dedicated key (e.g. keyboard Shift or Meta, if you're using the shoulders anyway)
- if there are so many dead diacritics and labeled special symbols, most people will not need Compose
Other than those remarks, it's certainly a layout I could live with.
There is a difference between "having language support" and being able to type a language from the point of view of the user.
AltGr+/diactrics is ok for interlingual use other than english, which is convenient to a lot of users, but the only thing good enough for real support is dedicated keys,
There is a difference between "having language support" and being able to type a language from the point of view of the user.
AltGr+/diactrics is ok for interlingual use other than english, which is convenient to a lot of users, but the only thing good enough for real support is dedicated keys,
That depends on the language. For German and Scandinavian, dedicated keys are the way to go. For Spanish, Portuguese, and French, a mix between dedicated keys (for çñé) and diacritics (for grave/acute/circumflex) is best. For Italian and Dutch, no dedicated keys are needed but diacritics are used.
Dedicated primary keys are nice to have, but we don't have keys to spare, so keeping 3 keys available for that comes at a rather heavy price imo.
+ and - on the game pad is duplicating + and - on the keyboard (waste of keys). It adds to confusion. "Whhich + do I press?" It hurts custom mapping - mapping + to 'grenade1' would mean loosing the ability to type the symbol +.
Not that I'm supporting _wb_'s decision to put +/- on the facebuttons (I wanted those at some point, but have gone to Ins/Del), but you don't have to worry about degeneracy. Numpad +/- give different keycodes than keyboard +/-, so _wb_ can safely assign two different keycodes to his two different -/+ buttons, so that they can be remapped without difficulty. (This blew my mind when I learned about it.)
I think my biggest concern with Saber's layout is exactly this sort of degeneracy, but with the three shifts. Will ED have three distinct keycodes for each shift? If so, they aren't exactly standard shifts, and may need tweaking in software to get it right. If not, then how can we remap them if we so desire? In either case, it seems better not to have three shifts, but rather only two.
call me a worry wart, but I'm still not convinced about bunching all those symbols { [ \ etc on the right side is going to work - it just looks like a difficult to use mistake - hope I'm wrong....
call me a worry wart, but I'm still not convinced about bunching all those symbols { [ \ etc on the right side is going to work - it just looks like a difficult to use mistake - hope I'm wrong....
(note: I found another subtle cleanup that could be done.)
They all come from the right side of the US standard keyboard. If you use one, that will be where you instinctively look there to find them.
Many of them are on the Fn and Fn+shift layer. It should not be a problem as Fn and Shift are together on the bottom left and should be easily chordable with the left thumb.
The 'paired' symbols that are on the Fn layer are the type where you'll generally type in both sides then left arrow one and fill in the contents.
Tab is essentially a long space. The Pandora had tab on space, but the implementation was bad since space was right next to the Fn button. With the Fn key on the left and space on the right, Fn+space=tab becomes a very easy combo.
This makes no sense to me. How is forcing the use of 2 fingers on opposite sides of the keyboard for tab better, when the Pandora allows you to press it with one finger in a single motion? (which to my mind almost a good as having a dedicated key for it) Much easier to trigger it with Fn and space together than not.
Thinking it through on the 5th and 6th game buttons, I don't think it's a great idea to have them tied to any key that is likely to be needed in communications/typing.
I'm curious what game you have in mind that doesn't separate text entry from action sequences. (and if it doesn't, do you really have time during action to be editing your text beyond the use of backspace?)
call me a worry wart, but I'm still not convinced about bunching all those symbols { [ \ etc on the right side is going to work - it just looks like a difficult to use mistake - hope I'm wrong....
(note: I found another subtle cleanup that could be done.)
They all come from the right side of the US standard keyboard. If you use one, that will be where you instinctively look there to find them.
Many of them are on the Fn and Fn+shift layer. It should not be a problem as Fn and Shift are together on the bottom left and should be easily chordable with the left thumb.
The 'paired' symbols that are on the Fn layer are the type where you'll generally type in both sides then left arrow one and fill in the contents.
I Like this layout, though I would suggest not separating PrtScn and SysRq as they are usually the same key (iirc SysRq is Shift + PrtScn on a regular US keyboard) and instead replace SysRq with Pause (which is also Break on a US keyboard) leaving SysRq = Shift + PrtScn just like on a full size keyboard. Would this not make more sense, especially given Pause/Break isn't otherwise present in this layout that I can see?
Also, why do << and >> need their own keys? I thought those were going to be numpad +/- and maybe Ins and Del.
I have not been following this discussion closely but looked at some proposals this weekend. The one thing that struck me is that many including _wb_'s tries to be an insane amount of everything at once. Compatible with everything != usable. If each button has so many keycodes that you need a third level modifier just to type in your language, then it is too much to read or print on keymat as well. That means you have to look it up, so why not have more layouts available and switch to a suitable one with limited need for modifiers as the Kingu's functional area? I would rather switch between two sane layouts than hitting modifiers, combobuttons and spend time reading too tiny keymat print.
We will need a third level modifier anyway. We simply don't have enough keys to avoid that.
Switching to a more suitable layout and tweaking the mapping to your personal preferences (while invalidating the labels on the keys) is always a possibility, no matter which labels we put on the keys.
The extra symbols in my proposal (äöüßçñéèàøæå) do indeed add a bit of visual clutter, but the advantage is that for nearly everyone, there's no need to remap anything at all.
This is not an advantage, its a solid disadvantage. The only serious support you get is Dutch, Catalan, and Swahili. If you are ok with language-modifiers in the wrong place. None of the stuff that matters most. German, French, Spanish, Italian, etc.
The option isnt not printing them, allthough that would be better, its allowing for real support as per how a typewriter/keyboard works, doing dedicated keys and language-modifiers as close to where they are supposed to be as possible. Additionally you can do hidden symbols, so who is that good for?
The "for everyone" mentality is only useful for interlingual purposes. And it can be employed as such, hidden. So why hidden?
If you look at the usergroup, and their languages, you disadvantage half the usergroup (the english people) by printing visual symbols.
The "advantage" of which, to get any efficiency, for nearly everyone (other than english people) you need to remap _the whole keyboard_.
Edit: As a sidenote, there are a lot more language-modifiers on my layout, they are just, you guessed it, hidden as per US-international defaults.
I'm really, really starting to feel the international symbols should be cut out completely. I don't mind people having them at their disposal, I want everyone to be happy with the product, blablabla. But purely personally especially the backlight will just "pop" that crap to my eyes to annoy me all the time.
It makes no difference to me what the layout is: like I've said, I'm sure I'll remap many things no matter which layout is chosen. But basically the visual appearance is just not going to appeal to me. I don't use scandinavian keyboards when I can avoid them on desktops... much less a scan-ger-span-franian.
So I'd just gladly pay extra for a C64 retrokeymat to make my Pyra do the retro thing properly! Not insane extra, of course, but lets just say I did not consider the 100 euro alu case for the Pandora as "too expensive" for something I use WAY more daily than my phone, microwave, car, toilet...
And even that C64 map would surely have less symbols than some layouts here...
Oooh... waaait... ooooooooh, first Ultima was 35 years ago next year, I think I can still read the alphabet without constantly looking up the symbols oh gosh that would just really rock... backlit futhark-clone alphabet lighting my magic box... oooooooooooooh.... I waaaaaaaant!
Agreed. I'm Canadian, so our laptops tend to have the compacted laptop equivalent to 105-key keyboards with US-104 printing in black, Fn-accessible numpad in blue, and Canadian Multilingual French in green... but those aren't backlit and the keys have much more room for whitespace on them, so I can just ignore the green text with a little effort.
...and, since they're using the ordinary compacted version of the US layout, I don't have to look at them and can type from muscle memory.
(When I need to type accented letters for names like André or words like sœur, français, and société on my desktop, I rely on having remapped Control_R to Compose on my US-104 keyboard. I do have Alt_R remapped as ISO_Level3_Shift via -variant altgr-intl -option lv3:ralt_switch but I only really use it for exponents and other things I couldn't originally find a compose mapping for like this emote. ¬_¬ )
My attitude toward the Pyra keyboard has been that, since I don't have the time or the know-how to keep up with the discussion, I'm just going to assume it's guaranteed to look horrible and cramped with symbols I'll never use and hope this thread will have enough success at paring that back that it can still impress the way my black Pandora does.
Tab is essentially a long space. The Pandora had tab on space, but the implementation was bad since space was right next to the Fn button. With the Fn key on the left and space on the right, Fn+space=tab becomes a very easy combo.
This makes no sense to me. How is forcing the use of 2 fingers on opposite sides of the keyboard for tab better, when the Pandora allows you to press it with one finger in a single motion? (which to my mind almost a good as having a dedicated key for it) Much easier to trigger it with Fn and space together than not.
For doing a single Tab, the Pandora way is probably better indeed.
For doing multiple (repeated) Tabs, holding Fn/Meta with one thumb (or on a modifier) while repeatedly hitting Space is going to be better than what you can do on the Pandora.
Tab is essentially a long space. The Pandora had tab on space, but the implementation was bad since space was right next to the Fn button. With the Fn key on the left and space on the right, Fn+space=tab becomes a very easy combo.
This makes no sense to me. How is forcing the use of 2 fingers on opposite sides of the keyboard for tab better, when the Pandora allows you to press it with one finger in a single motion? (which to my mind almost a good as having a dedicated key for it) Much easier to trigger it with Fn and space together than not.
For doing a single Tab, the Pandora way is probably better indeed.
For doing multiple (repeated) Tabs, holding Fn/Meta with one thumb (or on a modifier) while repeatedly hitting Space is going to be better than what you can do on the Pandora.
If the Fn key equivalent is going to be on the shoulders, then using that would be the best solution for handheld use. (especially if it's on the left shoulder) If the Pyra is in a dock or tabletop then the ergonomics are completely different anyway, and it becomes much easier to use multiple fingers on the same hand.
That said, I also have no problem holding down fn and repeatedly tapping space with the same finger to get multiple tabs on the Pandora.
You could use one shoulder+another for tab. For the purpose of implementing tab on the keyboard area, for reasons its much more convenient when not holding it, and less treshold of entry there, tab is best implemeted as tab.
/? on the space bar simply 'feels wrong'.
`~ on Fn layer means they're related diacritics spread to other keys Fn layers. Ideally, where possible, the diacritics should all be bonded at the Fn layer to their root symbols, though that does mean that their related symbols should be root keys.
Giving `~ it's own key has some advantages too. ` is commonly used in gaming to 'open console'. ~ is insanely useful in navigating command line Linux.
With the Fn and Shift keys on the left with both shoulders and main keyboard area, that diacritic area on the lower left is a bit of a funky reach.
Ins and Del 'feels right' since it pairs nicely with PgUp, PgDn, Home and End, but could get in the way if 'stolen' for in-game play. I.e. if they're mapped to the game, then we loose them for in-game text use. I can live with that, but thinking it through, it feels 'more right' to give those two buttons something semi-unique that isn't 'in use' for something else.
It no longer has separate dead tilde and grave, because I think it is not really necessary if àèùñ are available.
Spanish does not use graves, and the only tilde it uses is ñ.
In French, the only graves are àè (and ù for the word "où" -- yes, that letter is only used in specifically that word!), and there are no tildes, so that's OK.
In Portuguese, the only grave is à, but there's also ãõ. Portuguese does not use umlauts though. So they can either remap the German äö to ãõ, or they can make ~ a dead key (like in e.g. US-International).
In Italian, there are graves on all vowels, but àèù are the most common ones. They can make ` a dead key (which doesn't really hurt, since it's not really used for anything). Italian has no tildes.
In Dutch, the only grave that (rarely) occurs is è, so that's OK. It does not use tildes. Same with Afrikaans.
Estonian has õ, and they can't apply the 'Portuguese trick' because they also use üäö. They would have to map their õ to some available position, e.g. Meta+T. In any case they probably wouldn't want to use the dead diacritic method, because õ is a rather common letter in their language.
I don't think other major languages use grave or tilde diacritics besides àèùñ.
Meta/Shift shoulders on the left or on the right does not matter much -- I use L1 for shift on the Pandora, and I notice no big difference between writing a capital Q and a capital P. But even if there is a difference, then I rather have them on the left, so the punctuation symbols on (Shift+)Meta get priority.
I think the action button thing is no problem: it will not interfere with games. If games let you type so much that Ins and Del are useful, then surely Home and End would also be useful, and the dpad for that matter? After all, if you can't move the cursor, what's the point of Ins and Del? So I wouldn't worry about it.
English: just try to manage to ignore the funny letters
Spanish: ñ is at Meta+N, acute is available as a mashable dead key on Meta+'
Portuguese: ç is available on Meta+C, acute at Meta+', circumflex at Meta+>, à at Meta+A. You would probably remap äö to ãõ.
French: é and à are available as mashable combos on Meta+Z and Meta+A, èùç are at Meta+EUC, circumflex at Meta+>, diaeresis at Meta+"
German: üöä are available at Meta+YGH in a cluster that resembles the German keyboard ÜÖÄ cluster. The left thumb can hold Meta while the right thumb types üöä. ß is at Meta+S.
Italian: àèùé are available. ìò are not available, so you either map them as direct keys somewhere (e.g. Meta+DF), or you make backtick ` a dead grave.
Some examples for smaller languages:
Dutch: diaeresis and acute are available. For loanwords (or Afrikaans), circumflex is available.
Scandinavian languages: your letters are available, not in particularly nice spots and not as dedicated primary keys, but at least you can type without having to remap or remember things.
Polish: ąę can be made using Meta+, (or you could map them to Meta+AE), ćńóśź can be made using acute at Meta+', ż can be made using Meta+. (or you could map it to Meta+Z), Ł is missing so you would have to map it somewhere (e.g. Meta+X).
Czech: áéíóúý can be made with acute (Meta+'), ČĎĚŇŘŠŤŽ can be made with caron (Meta+<), ů can be made with dot/ring (Meta+.) or could be mapped to e.g. Meta+U.
Hungarian: áéóú can be made witht acute (Meta+'), the German öü can be used, and for the double-acute őű you either remap Meta+" to double-acute, or you remap e.g. ØÚ to ŐŰ.
Turkish: çöü are available already, ş can be made with cedilla (Meta+,), ğ can be made with caron/breve (Meta+<), dotless i (ı) can be made with Meta+. Alternatively, şğı can be mapped to available Meta keys, e.g. Meta+DFT.
My thumb typing on tablets doesn't have any "muscle memory" from a full sized keyboard, just because a full sized keyboard does it that way is no justification for doing it on a smaller keyboard, potentially quite the reverse!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.