- Joined
- Jan 18, 2010
- Messages
- 11,418
Actually I posted that in IRC.. damn Wizardstan taking my thunder...
Unofficial Keyboard Layouts
- Thread starter Saber
- Start date
Saber
Advanced Member
- Joined
- Jan 23, 2012
- Messages
- 1,303
If you give the Right Keyboard Shift a Fn value, wouldn't it hinder a Shift + Fn combo with that key then? Also, if the Right Keyboard Shift is Super, how does it act like Super(Windows key?) when a person wants it to when it isn't a Shift key?
If we have an AltGr key there won't be too great a need for all those diacritical marks to reside as they do in your proposal, assuming we can print them on the small keycaps anyways. Acute, Grave, and Caret as dead keys should cover the basics. Compose under Fn + Spacebar or Left Shift + Enter should do the rest. AltGr for the Swedish layout seems extensive for special characters as an example. If we do have an AltGr on the layout(with the Dead keys and some umlauted vowels), Compose will be almost superfluous then.
Saber
Advanced Member
- Joined
- Jan 23, 2012
- Messages
- 1,303
Updated layout.
Insert to (+) face button.
Nub centers are tactile left and right mouse button clicks. Right nub unceases to also be mouse clicks like on the Pandora.
Context Menu key to Fn + Spacebar.
Select under Start and not side by side?
While an inconsiderable ergonomic flaw resurrected from the Pandora, it's deduced to simplify keymat prototyping with a correlating reduction in associated costs. In plain English, it's familiar, uninspired, and cheaper to do it that way again.
However, it's my partiality so I left it in my layout proposal.
Insert to (+) face button.
Nub centers are tactile left and right mouse button clicks. Right nub unceases to also be mouse clicks like on the Pandora.
Context Menu key to Fn + Spacebar.
Select under Start and not side by side?
While an inconsiderable ergonomic flaw resurrected from the Pandora, it's deduced to simplify keymat prototyping with a correlating reduction in associated costs. In plain English, it's familiar, uninspired, and cheaper to do it that way again.
However, it's my partiality so I left it in my layout proposal.
Last edited by a moderator:
Caine
Hardcore Member
It was a bit of a hyperbole, intended to drive the point that shadowing valid keyboard combinations is unnecessary and very annoying when it bites you.
Why I didn't report it? I don't report bugs all that often to be honest (yes, bad, I know).
I haven't used my Pandora in nearly two years, I don't remember if I actually had the issue.
If I did then either it was not bad enough or I disabled it in the keyboard mapping/changed it in the applications that were using it.
The Pandora keyboard layout was pretty annoying in several ways (e.g. shift+backspace), so I did change stuff around quite a bit.
My post was intended to avoid such mistakes this time.
Yes, in my proposal, if keyboard RightShift has an Fn value, you can't do Shift+Fn with it. You can still do Shift+Fn using one of the two other shift keys though. The easiest way to do Shift+Fn would be to hold L1+L2 anyway.
To make it act like a Super key it would suffice to comment out some lines in a configuration file to undo its being configured to behave as another shift. Of course we could make a GUI config tool for that or reuse some existing tool.
Acute, Grave and Circumflex are maybe enough for languages like French, but it depends completely on the language which other ones you commonly need. E.g. in Dutch you need umlauts on ë and ï too besides the German äöü, in Balto-Slavic languages you will need the háček a lot for č š ž etc, the macron is used in some languages but is also used a lot in transcriptions of e.g. Arabic or Japanese, and so on. But yes, we don't strictly need all of those dead key diacritics, as long as there's a convenient compose key (a dedicated key if you don't need the right keyboard shift).
Saber
Advanced Member
- Joined
- Jan 23, 2012
- Messages
- 1,303
I think it's a bit of overkill to have all the diacritics you have on your layout when you can generate most of those with AltGr set to a specific local dialect set. As an example, if I use the Latvian AltGr set, I'm able to produce č š ž and their uppercase variants using Shift, AltGr, and c, s, and z.
I know you mean well by what you've done though.
Well, my opinion is the Select key's position is one of the more difficult keys to press on the Pandora which is ideal placement for Escape, a key we definitely don't want to press accidently.
Do you have your own idea of where Escape should go Natsu?
For me if ED can't or won't put Select by Start, I'd place Escape in one of three places:
1. Fn + PYRA
2. Fn + q
3. Fn + Tab
Number three is my favorite.
Last edited by a moderator:
Yes, changing the keymap will always be the best option if you frequently type in a specific non-English language. But it is a bit inconvenient to switch between different layouts, and to have keyboard labels that don't match the keymap.
My layout attempts to be convenient for as many Latin alphabet-based languages as possible, with labels matching the layout and no remapping needed. If you only occasionally need e.g. ž, say to type a name like Slavoj Žižec in a document in English, it's practical to have that diacritic right on your keyboard, without having to switch keymaps, and without having to remember that the diacritic is called a caron or háček and can be entered with [Compose] c <letter> (c for caron I assume). Or if you want to type Tōkyō or Allāh or Ångström or Brontë or Nestlé or Citroën or the reduced Planck constant ħ or the Polish złoty or a piña colada or words like naïve and résumé.
Here is my latest proposal, maybe you could put the link to it also in the first post? http://www.keyboard-layout-editor.com/#/layouts/46d8f52be8fefc483ddd296c0945c2ed
Also, are you currently proposing to have an actual AltGr key, different from the Fn/Meta key? Only available as a shoulder button, and no shoulder button for Fn?
I think it would be confusing to have that many values per key. So you would have e.g. z, Z, /, ž, Ž all on the same key? Maybe even AltGr+Fn+Shift combos, for up to 8 symbols per key? I think that's too much. And I also want to have Fn/Meta on a shoulder button.
Not really. Squeeze it next to 1? I just don't like that placement. You have the keys and game buttons all in its own area then you have this one key there. Other words, it just seems out of place.
2.>>>3.>>>>>>>>>>>>>>>>>>>->1.
Saber
Advanced Member
- Joined
- Jan 23, 2012
- Messages
- 1,303
Added your proposal to the first post.
Yes, I do want a geniune AltGr key on the L2 shoulder button. Probably the best place for it if we will have one as it will act in concert with L1's Shift for uppercase diacritical alphabeticals. I'd also prefer to have the main character modifier be called recognizable Fn, even if it isn't a hardware based one.
Thanks Natsu for your feedback.
Escape placed where Select is on the Pandora seems a good way to prevent it from being pressed by mistake easily. There's a reason every keyboard has it banished to the upper left corner away from the other keys. On the Pyra I imagined, it won't be quite as isolated though as Start(Alt), Select(Control), and Pyra("Menu") are close by, but it won't be easy to press as they will be which is advantageous.
Last edited by a moderator:
comradekingu
Glowing ember
Consider the following:
Even people without <>-key (105) can agree that works well for coding while staying compatible with intl layouts.
Even people without <>-key (105) can agree that works well for coding while staying compatible with intl layouts.
Last edited by a moderator:
But then there is no Fn on the shoulder buttons?!Added your proposal to the first post.
Yes, I do want a geniune AltGr key on the L2 shoulder button. Probably the best place for it if we will have one as it will act in concert with L1's Shift for uppercase diacritical alphabeticals. I'd also prefer to have the main character modifier be called recognizable Fn, even if it isn't a hardware based one.
I think it's really important to have Fn (or however we call it, Fn is fine for me, though Meta sounds nice to me too) as a shoulder button too, since besides Shift it is the most commonly used modifier key (at least for me).
Having both AltGr and Fn is confusing in my opinion: 8 symbols per key is overkill, 4 should be more than enough. If you really want an AltGr key, you can remap a key to it. If you really want, you could map left keyboard shift to AltGr, right keyboard shift to Super, R2 to Hyper, so you end up having 7 modifier keys (Shift, Control, Alt, Meta/Fn, AltGr, Super, Hyper) so you can have 128 symbols per key -- a full keyboard per key!
(if you do some coding, you could even go further and assign new modifier keys to L2 and SELECT too, and have 2^9 = 512 symbols per key)
comradekingu
Glowing ember
Having modifiers on the L/R buttons is just as good an idea as having a full keyboard underneath to use with the fingers and gamecontrols atop to use with thumbs.
Its probably genious if one learns to use it, but it is something people avoid.
Touch typing is something i avoided somewhat until i got blank metal keycaps. Still on qwerty. Old habits die hard.
Its probably genious if one learns to use it, but it is something people avoid.
Touch typing is something i avoided somewhat until i got blank metal keycaps. Still on qwerty. Old habits die hard.
Last edited by a moderator:
That's why I don't propose to take away the modifier keys on the keyboard itself -- I realize that a lot of people don't (want to learn to) use the shoulder buttons while typing. You can even have two shifts on the keyboard itself, an Fn/Meta key, and Ctrl (select) and Alt (start). Those are five keys that are redundant to me -- but that's OK, I can remap them to other things or just ignore them.
The important thing though is that all modifier keys are on a shoulder button. On the Pandora it is very annoying that Alt is not on a shoulder button -- I basically have to change all shortcuts that involve Alt to something with Ctrl or Ctrl-Shift. Fn is less of a problem since it is sticky, but it would still be better if it was also on a shoulder button.
Also I think we should make all keyboard modifier keys sticky, not just Fn. That's the only way to make them work well -- I don't see how anyone can do Ctrl-Alt-<something> or Ctrl-Shift-<something> on the Pandora while holding it as a handheld and without using shoulder buttons. Also, sticky modifier keys would mean that we don't really need an extra shift key on the right side of the keyboard. (Of course the modifier keys on the shoulder button should be non-sticky.)
Majin Wamu
Powered by Pixels
The keyboard layout is looking pretty dang good.
I still dislike to have Fn/Meta on the shoulder buttons.
The shoulder Buttons should be for Gaming and easy accessible.
A Modifier isn't.
You can't tell any game by default to use a modifier as normal Keypress.
At least it should not be a fixed button like Pandora Fn Button.
The shoulder Buttons should be for Gaming and easy accessible.
A Modifier isn't.
You can't tell any game by default to use a modifier as normal Keypress.
At least it should not be a fixed button like Pandora Fn Button.
But that's exactly how it is on the Pandora: L1 is RShift, R1 is RCtrl. What is the problem? You can easily detect those keys in any application, including games (and even differentiate them from LShift and LCtrl). OK, maybe some games have a GUI to let the user modify keys, and maybe some of them don't support modifier keys as game buttons, but that is easy enough to fix -- in the worst case, you need a little script that remaps the shoulder buttons to something else before launching the game, and restores them afterwards.
On the Pandora, the shoulder buttons and also START and SELECT are modifier keys. This is not a problem. It only means that in quick ports, the game or application will call the buttons ALT and HOME and PGDN instead of START and [A] and [X]. But that has nothing to do with those buttons being modifier keys or not.
The only problem with the Pandora's Fn is that it's not a modifier key, but a low-level ("hardware") key that cannot be detected by userland software. But that is going to change anyway on the Pyra.
If the shoulder buttons are not modifier keys, what else would they be? Some have suggested to put commonly used keys like SPACE and ENTER there, but I think that's a bad idea for several reasons:
1. Modifier keys have the advantage that normally, if you press them, nothing happens. This is practical because it is easy to accidentally press shoulder buttons. If you would put ENTER or SPACE or "." or anything like that on a shoulder button, unexpected stuff could happen like when you are editing a document and put the Pyra in your pocket, the document gets messed up with lots of newlines and spaces because your pocket is pressing the shoulder buttons.
2. Modifier keys are used in combination with other keys, meaning you have to hold them while pressing another key. When thumb-typing, you only have two thumbs, meaning that ideally you need all modifier keys on both sides to be able to comfortably make combinations, and even then, it is hard to do multiple modifiers at the same time (e.g. CTRL-ALT-F1).
3. A key like SPACE only occurs once on a normal keyboard. That means that if you also put it on a shoulder button, most applications will not be able to distinguish the keyboard space from the shoulder button space, so you can't use both of them at the same time. Modifier keys don't have that problem because there are always two of them on a normal keyboard, and most applications can distinguish them.
4. I don't think any key, except maybe SPACE and the letter E, is used as frequently as the modifier keys -- especially in German, you need SHIFT a lot, but also Fn/Meta will be used a lot since so many keys have dual labels, and CTRL and ALT also very commonly used in all kinds of shortcuts. E.g. I tend to swap a lot between windows (with CTRL-UP/DOWN on my Pandora, or probably ALT-TAB on the Pyra) and terminal/browser tabs (CTRL-PGUP/PGDN), or do stuff like cut/copy/paste/undo (CTRL-X/C/V/Z) or close windows/applications (CTRL-W, CTRL-Q). Since shoulder buttons are so easy to press, it makes sense to put the most frequently used keys there.
5. It is easy to hold down a shoulder button while doing other stuff. This is another reason why I want modifier keys on the shoulder buttons, since modifier keys are keys you often have to hold down for a while, e.g. when switching between tabs I need to hold CTRL while I press PGUP or PGDN multiple times, or on the Pandora when I'm moving a window using SHIFT+drag. E.g. in the Gimp, you sometimes need to hold CTRL, ALT and/or SHIFT while dragging or clicking the mouse -- imagine pressing START, SELECT, and keyboard SHIFT on a Pandora while moving the left nub and pressing the right nub. Impossible I would say. By contrast, keys like SPACE or "." are keys you rarely have to hold down, and certainly not while doing other stuff.
- Joined
- Jan 18, 2010
- Messages
- 11,418
Sure the CTRL and Shift buttons can be detected, however FN and Meta keys generally can't be. Then there is the what if question when you need to have all the shoulder buttons used in a game, but also need the meta keys for keyboard input.. so I recommend not having meta's keys as shoulder buttons.
About the scripts, ones like that tend to break when applications crash or exit improperly and then there are hundreds of forum posts about shoulder buttons stop working like with the nubs currently on the Pandora.
slaeshjag
¯\_(ツ)_/¯
The "modifier keys can't be detected" argument is pretty moot. Assuming things are done the right way this time, the special modifiers will also generate gamepad events.
- Joined
- Jan 18, 2010
- Messages
- 11,418
Okay, sure... What if a game needs all the shoulder buttons and requires use of one of the keyboard keys that requires a meta button to press?
