Very true. I think he chose yours because of its similarity to the Pandora. I think some of us were hoping for a keyboard that would be more than what the Pandora's was, but perhaps the Pandora's keyboard is already close to perfection.
While it shares some things from the Pandora layout, inevitably he chose mine because he knows it will work(with some minor changes). It doesn't rely on the shoulder buttons while held in hand and it places all the important constant punctuation to the left side, away from the key, AltGr, that will induce them. It also doesn't demote the hardware keys(the four up top) as reserves behind keys like Escape or Delete, because the person using those for them in their layout couldn't find a satisfactory spot for Escape and Delete near or in the keyboard's rows.
I personally think any of these layouts will work, though I am happier with some than others. (I don't "LOVE" any layout, however, not even my own, because the design constraints are too severe for me.) And "Couldn't find a satisfactory spot for Escape and Delete" is a strawman. We have different design criteria than you; if we wanted to put Esc on Meta+Q, we could easily do so (especially _wb_'s latest: http://www.keyboard-layout-editor.com/#/layouts/e1b05961a2c31a6b89288597b9642ae6 ).
[edit] And of course _wb_'s can be modified to put insert and delete on the +/- facebuttons, as I do. But in my Unofficial poll, that actually wasn't something people cared too much about, which was interesting to me to find out.
Enough please with the strawman reference. It's incredibly stale and overused on this board.
ED is putting hardware toggles on the four keys up top nearest the Power button. Escape is not a hardware toggle so it won't be up there. Neither will Delete or Insert so forget about it. As for + and - and their relation to browser zooming, AltGr + d or f is hardly challenging to do, which is where those symbols should go. You yourself said how important /= and =\ pairs are in coding and I think /- is as well, so having them so far apart is a poor idea.
One more thing though about diacritics. If I had my way, if only to please some of you, I would do them like the following:
AltGr + u is dead Umlaut.
AltGr + i is dead Circumflex
AltGr + j is dead Grave(regular Grave is on AltGr + h and Euro is back on AltGr + n)
AltGr + k is dead Acute.
That covers most of the important ones by default and we still can remap over them, or over Section Sign, Euro, and Micro. These four symbols would have a line or box under them like with this keyboard's diacritics. Something that tells the user they aren't your average key when pressed. That's how I would do it.
001As promised earlier in my news post, here is the thread about the keyboard layout.
002
003First of all, thanks for all the discussions and threads you already had here at the boards - a few interesting ideas arose, and one came very close to what I had in mind.
004
005Let's start with some facts first:
006The keyboard should be standard enough to be used by every normal user
007It should be balanced between text typing and coding
008It should have most of the keys a normal keyboard has (i.e. Pandora keyboard has issues with DosBox).
009The main languages used where the Pandora sold are English, French and German. It should support these languages as good as possible (with English being the main one)
010We should have a maximum of three characters per key: One with a single keypress, one with Shift and one with AltGr (which replaces the old Fn-Key)
011The most-used keys should get the best positions
012The keyboard will have two different colored labels (so basically the same as the Pandora had).
013Adding more colors will make things more expensive, and the keymat IS already more expensive because of the backlight.
014Okay, of all the keyboard layouts I've seen at the threads you created, this seems to be nigh perfect in my opinion:
017Mostly Standard QWERTY-Keyboard, including the Shift-Keys on the numbers
018Tab as a single key
019ä, ö and ü (German) as well as ' and ` (French) included
020Almost all normal characters are existant
021Even has two shift keys (useful for persons who don't use the shoulder buttons when typing, like myself
022What issues are there?
023Hard to type some key combinations like ALT-F4 (as you need to press ALT, ALTGr and 4 at the same time). Only used for old DOS-Games though
024ESC is not a single key. Would be nice to have it, but not mandatory (did work with the Pandora)
025Some keys missing: ', ° and ^.
026+, - and = is a bit too far in the middle (hard to reach for these common keys). Maybe we should move them with less used keys?
027What I cannot tell is:
028How is the layout for devving (vim, scripts, code, etc.)?
029All needed characters there?
030Can most used characters be easily reached or do we need to move around a bit?
031What do you think?
032Please post any issues and suggestions you have here - so we can rearrange everything a bit so it's useful for everyone.
033But please do NOT post completely different keyboard layouts... we had a lot of those already.
034Instead, post why you like a different one better and link to it on the existing threads.
035And be rational - there is NO layout everyone loves. What we need to find is the best compromise for all users and usecases.
I consider your layout more a lesson in ill-restraint. It's author fails to notice that few will want to chord AltGr and Shift together for things like { and } or _ and + if only because a full-size keyboard has those keys in normal shifted positions. It'll be a disaster commercially for the project and an inferface nightmare to have to press a Shift and Fn/AltGr for those keys everytime.
Clearly you're missing the whole chording modifiers concept - or choose to ignore it - or you're in denial.
EVERY layout does it - they just gloss over the fact. Any key that creates a character on Fn that has an 'upper case' version (non-English letters) MUST have Fn and shift+Fn values. The additional letters for the German alphabet SHOULD be present and easily accessible from the keyboard in both upper and lower case. According to your statement it is a horrendous strain to do a combination of Fn+Shift+key and should be avoided at the expense of the project. Yet your keyboard REQUIRES these exact same key combinations to type in German.
See EvilDragon's requirements message lines 006, 008, 019.
All keys should exist and should be labeled as such on the layout. The function of a key should be no mystery to the end user. It should be clearly labeled as to it's default activity.
See EvilDragon's requirements message lines 006, 008, 024, 025, 026
As for AltGr, it behaves exactly as an AltGr key does. On every keyboard that has this key, a certain unique set of symbols and characters are produced, for that particular regional keyboard. Our AltGr will generate our own customly arranged set of distinct symbols. Very straightforward.
A, "Real AltGr", key yields expected mappings from the base keyboard layout to the localization layout for the keyboard. Examples: http://en.wikipedia.org/wiki/AltGr_key
This is how you can take a US standard 101 keyboard and tell Linux (or other OS) that you're typing in Belgian and magically the right alt becomes AltGr and AltGr+H yields ħ and AltGr+Shift+H yields Ħ.
The REAL fact is that EVERY one of the above keyboards has an AltGr key already - whatever is mapped to the right Alt key. When keyboard localization is set for non-English, they will, in effect, be able to use an AltGr mapping of even Shift+Fn keys by setting the localization to a non-English keyboard and selecting Shift+Fn+AltGr(right alt) and a key.
I did not realize this before I did a s-ton of research. I suspect EvilDragon may not have understood the ramifications when he made statement 010 above, or maybe did not understand that what your keyboard was calling AltGr is not, actually, a true AltGr key.
EvilDragon DID say on line 014 that he considered the Saber layout to be near perfect.
However, we now know that it fails requirements on line 008, 011.
According to lines 023, 024, 025, 026, EvilDragon Had some issues with:
023Hard to type some key combinations like ALT-F4 (as you need to press ALT, ALTGr and 4 at the same time). Only used for old DOS-Games though
024ESC is not a single key. Would be nice to have it, but not mandatory (did work with the Pandora)
025Some keys missing: ', ° and ^.
026+, - and = is a bit too far in the middle (hard to reach for these common keys). Maybe we should move them with less used keys?
None of the above issues have been addressed in your layout. Alt-F4 is still a pain in the ass. Esc is not a single key. I don't see ° anywhere on the current Saber layout. The + and - keys are still in the lower left quadrant far, far away from the upper right corner where they appear on a 'standard keyboard'.
On lines 016 through 032 he expressed doubts AND asked for the community to evaluate it for application use.
On line 031 he explicitly asks for community opinions. If this were a 'done deal', he could/would have simply said, "We're going to do THIS one." and the community would have gone ape shit.
EDIT: After looking at your layout more closely, I really don't know why you suspect anyone will be okay with : on Shift + Fn + g. Didn't you bother reading anything of what ED said in the Official Keyboard thread?
Yes. I did. Did you? You didn't make appropriate changes to address his requirements and concerns or the issues that he stated with your initial design. I have done my best to meet every requirement he stated, including DosBox (and QEMU) compliance, keys in or very near standard positions, English first, but built in features for additional language support with dedicated German letters, easy Diacritics for French and a Compose key for whatever wouldn't fit.
In order to have a contiguous F1-F12 row, there is no room on that row for additional symbols on that row. So, []\ and their pairs had to move down one row. This displaced ;' and their pairs 3 keys to the left so that ;'[]\ and their pairs are in a 5 key series. They're still all with their native pairs. They're still in the same order left to right, top to bottom, and in the same quadrant of the keyboard as they are on a 'normal' keyboard. The ; and ' keys merely moved 3 spaces to the left to make room for the [ ] \ keys and their pairs.
Yes, on my keyboard Shift+Fn+G is the 5th key over from the right on row 3 and with my keyboard resolves to :.
On your (Saber's) keyboard, Shift+FakeAltGr+G resolves to Ü, which is a standard character in the German alphabet.
: on Shift+Fn+G
is no worse and no better than
Ü on Shift+FakeAltGr+G
Either one is pretty easy to hit since we can both chord Fn+shift. Why are you making a big deal about something YOUR keyboard does using the SAME mechanism?
My layout violates ONE of EvilDragon's feature requirements list.
010We should have a maximum of three characters per key: One with a single keypress, one with Shift and one with AltGr (which replaces the old Fn-Key)And yes, I am blatantly choosing to not follow this rule. I suspect it was declared without enough thought to the ramifications. I.e.
If this rule were followed:
1. Not being able to create capital German letters without Fn+Shift. ALL of the above layouts with German key mappings (Stated or not) MUST be Fn+Shift compatible in order to create upper/lower characters on Fn/Meta/FakeAltGr keys.
2. Not being able to create a DosBox compliant layout as requested in 008. DosBox and QEMU both require the symbols from the US English keyboard to retain their paired sets. There simply are not enough keys on a Pyra to give each letter of the English alphabet AND the symbol keys all their own dedicated top level keys. Therefore, if we want the layout to play well with these two rather important emulation platforms, we MUST have 4 symbol keys with normal, shift, Fn, Fn+Shift level assignments.
3. AltGr has a VERY specific meaning outside of the Pyra keyboard with regard to international layouts and could be activated by an end user on the Pyra's right Alt key REGARDLESS of what we put on the key caps for the Fn/Meta/CallItAnythingButAltGr keys. The Fn/Meta/CallItAnythingButAltGr key CANNOT be a true 'AltGr' key and function properly. I suspect that EvilDragon did not fully grasp this when he made the above statement/requirement.
There are 4 keyboards in this poll thread that conform to EvilDragon's requested specifications much better than the Saber layout that was originally picked as an example of what a 'Great' layout should look like. I don't see it as a 'slam dunk' for the Saber layout. Sorry Saber.
Very true. I think he chose yours because of its similarity to the Pandora. I think some of us were hoping for a keyboard that would be more than what the Pandora's was, but perhaps the Pandora's keyboard is already close to perfection.
While it shares some things from the Pandora layout, inevitably he chose mine because he knows it will work(with some minor changes). It doesn't rely on the shoulder buttons while held in hand and it places all the important constant punctuation to the left side, away from the key, AltGr, that will induce them. It also doesn't demote the hardware keys(the four up top) as reserves behind keys like Escape or Delete, because the person using those for them in their layout couldn't find a satisfactory spot for Escape and Delete near or in the keyboard's rows.
I personally think any of these layouts will work, though I am happier with some than others. (I don't "LOVE" any layout, however, not even my own, because the design constraints are too severe for me.) And "Couldn't find a satisfactory spot for Escape and Delete" is a strawman. We have different design criteria than you; if we wanted to put Esc on Meta+Q, we could easily do so (especially _wb_'s latest: http://www.keyboard-layout-editor.com/#/layouts/e1b05961a2c31a6b89288597b9642ae6 ).
[edit] And of course _wb_'s can be modified to put insert and delete on the +/- facebuttons, as I do. But in my Unofficial poll, that actually wasn't something people cared too much about, which was interesting to me to find out.
Enough please with the strawman reference. It's incredibly stale and overused on this board.
ED is putting hardware toggles on the four keys up top nearest the Power button. Escape is not a hardware toggle so it won't be up there. Neither will Delete or Insert so forget about it. As for + and - and their relation to browser zooming, AltGr + d or f is hardly challenging to do, which is where those symbols should go. You yourself said how important /= and =\ pairs are in coding and I think /- is as well, so having them so far apart is a poor idea.
I think you may have misunderstood me here. By moving Ins/Del to the +/- face buttons, and by moving Escape down to Meta+Q, _wb_'s layout conforms to hardware buttons only for the top 4 (or actually 5) keys, and so nullifies your argument against at least his keyboard. And for the other layouts, we were simply not aware of ED's design criteria that "Only hardware buttons should be in the top 5 keys". And so, strawman or not, your argument of what is possible with non-Saber keyboards seems quite invalid. If it is a constraint, the layouts can adapt to them. Here's (one way) how to modify _wb_'s to conform to your ED's specifications:
If ED has a clear idea about what he wants to do, then ED designs and decides the layout. Meanwhile its not possible to just rule in a few things here and there and have the whole make sense.
AltGr meta + c is dead Cedille AltGr meta+ u is dead Umlaut. AltGr meta+ ir is dead CircumflexRetroflex AltGr meta+ jg is dead Grave AltGr meta+ ka is dead Acute
What about something like this with the corresponding symbols on each respective key?
Some button+some other button isnt something im going to remember.
I don't get the endless keyboard layout threads. Surely it's getting tired now?
We will end up with a fairly satisfactory layout in the end. Not everyone will be pleased.
The idea is to end up with an optimally satisfactory layout, not just a fairly satisfactory layout. We're getting close.
Anyway, here are my brutal criticisms
comradekingu: Your wobbly space button feels more like a stubborn statement to criticize the double-width space bar design decision, than a serious proposal. Also, while I appreciate the "less is more" approach, I think you went too far with it. Also the abundance of strange new or obscure icons makes it look like Egyptian hieroglyphs trying their best to resist getting deciphered by a casual onlooker.
If people dont like the symbols, then we have to print their names. This is no different to any other layout, its just part of the visual layout, and can be changed at will. I have to test things like that to see if people understand it.
Both are orthagonal issues. Either do it or dont.
Right now all the layouts voted over have something other than space on the space-bar. I'm seeing "+=" or "super", all with orange+
While i think its better to have two functions as two keys, and that there are no benefits to longspace other than visual recognition, it does pose these problems.
Longspace is: Visually recognisable (as something that is in the "wrong" place. Bringing that attention to an unsymmetrical key isnt good) Floppy by default. If you press "the middle" it will depress one side first, just like on the pandora, because there are no stabalizers. Avoid issue by seperating, or dont. See post Only usable from the left side, as if it was just the left side of the button, because that is always more central. The right side is never preferable so no benefit to a wider button functionally.
Something that consists of two buttons on the PCB, which means its not something that can be wasted, because then a full layout isnt possible for anyone.
I could just do two modifiers on it (shift and altgr) and not have it be two primary presses. But then i would need to put "." on <> I think that stands out as shoehorn-design. Thats the level of seriousness i want. Something other than "the button" on space, tab, enter, backspace, is just drawing attention to how few buttons there are. Like there are _too few_. Where _too few_ is where it gets ugly seemingly by default.
So the only difference is you cant press the middle and expect to get a result, which you dont(?)(atleast i dont), and wouldnt do anyhow. Maybe if it was space only people would be tricked into doing this.
On the pandora im forever wondering why i cant just press tab without the FN. There is no second layer to tab, so having the FN button next to enter and (space+tab) just wastes any and all short-hand combos you could get out of it.
With my placement of shift, you get { } > and : in ways that are better than normal secondary, where normal secondary requires two hands.
Do you guys mind just keeping to one thread? We don't need another 50 threads each day dedicated to keyboard layouts, it'll just delay ED's decision even more as he has to read all the responses.. ESPECIALLY IF YOU REPEAT YOURSELF OVER AND OVER AGAIN.
FWIW, I suspect that having Fn/Meta/Alt/whatever we're now calling it on a shoulder will make all these layouts better than the Pandora's one as is, because personally I find chording fingers easier than chording thumbs for some reason.
My only concern is that layouts that have shift and fn on the same side, assuming those need to be pressed together to get a lot of characters - how easy is it to press both the same side triggers together? Only ED can make an assessment of that at the moment though.
If L1+L2 is hard to chord, then of course shoulder Meta should be moved to the right in my proposal. I'm assuming/hoping that all shoulder combinations are easy to perform.
FWIW, I suspect that having Fn/Meta/Alt/whatever we're now calling it on a shoulder will make all these layouts better than the Pandora's one as is, because personally I find chording fingers easier than chording thumbs for some reason.
My only concern is that layouts that have shift and fn on the same side, assuming those need to be pressed together to get a lot of characters - how easy is it to press both the same side triggers together? Only ED can make an assessment of that at the moment though.
Yes, this is true. However, I don't think it's a big problem.
Desktop applications don't really look at raw keyup/keydown events, they use a higher level input abstraction. They won't care about modifier key events, especially not modifiers they don't even know exist.
So it's mostly a potential problem for games.
For Pyra-native games, there's obviously no problem.
The problem could be with ported or emulated games. If you have a game that uses both the F-keys and two pairs of shoulder buttons for game input, then there is a big problem, since you wouldn't be able to use the shoulder Fn/Meta modifier to produce an F-key without also producing L2 events.
Now, as far as I know, the number of game devices that actually have both F-keys and shoulder buttons is zero. PC-games may use F-keys, console games may use shoulder buttons, but I don't think there is any type of game that originally uses both the F-keys and the shoulder buttons.
Of course you could still have a PC game which uses F-keys, where you want to remap some of its most important game keys to shoulder buttons. In that case you either have to remap the game keys that are on F-keys to something that does not involve Fn/Meta (say, the number row or letters), or the Fn/Meta shoulder button (and potentially the other shoulder buttons too, because all modifiers can cause this type of problem) temporarily has to be mapped to something else so it no longer interferes -- but then of course you can no longer use it as a modifier key to input F-keys (you would have to use the keyboard modifier key).
Sorry @comradekingu & @_wb_ but I still don't understand how it works.
If I sumup, you have 2 Meta/AltGr, one on the main Keyboard, one on the shoulder.
To press F1, I need to press Meta + 1
My question is still the same.
In an SDL loop, I expect, when pressing F1, to get only SDLK_F1 event.
But I expect also to get some event when pressing any of the Shoulder (like we have SDLK_RSHIFT & SDLK_RCTRL on the Pandora).
So, either the Shoulder as Meta is configurable (like todays the nubs, that can be switch to Mouse / MButtons / Absolute by script), or there is something I don't understand.
(but sorry if it was explained somewhere in the multiple thread, there is just too much to read for me).
Edit2: Meta ≠ AltGr. You either have real AltGr, shift, ctrl, alt, on both keyboard and shoulders, or you dont. When you dont its because you have shoulder-meta. Thus needing to explain which one of the earlier candidates it takes over, and the problems that arise from it.
Doing it one way is a problem that solves itself, (see earlier post) and doing it the other way makes it a little easier to type F-keys for pros. (shoulder+keyboardbutton instead of keyboardbutton+keyboardbutton) Its also closer to pandora-layout, which some people seem to find intrinsic value in...
Lumping AltGr in with F-ingMeta brings a whole heap of issues, in short the reason why meta cant be called an AltGr. In any sense of AltGr usage. This key has a lot of expected functionality that it breaks. Like typing third level symbols on the typewriter-part. (Note, the typewriter part is _not_ where the symbols from the number row is supposed to be.)
Edit0: To answer your question, you can write an udev driver that takes keyboard scancodes and sends joystick-events instead. Then call that whenever you want to switch. Again, you need a different button to switch with, and put it on the user to do so, so its not sexy at all.
F-ingMeta on shoulders doesnt work if you want to have 4 gameshoulders.
Defeating some of the reason to have it there in the first place. Its no longer more effective for pros. Pros whos mental mapping breaks not only for regular keys that people are used to, but also for a different concept, implemented as a nonstandard-key. The less meta does the better, ideally it should _only_ do the things it needs to do. F-keys and mediabuttons. You also normally have one less mediabutton-shoulder if you have meta-shoulder. (unless you want to hack up something for keyboardmeta+shouldermeta. But again, conflicted concepts working half-way)
You can re-implement meta on the keyboard part, and you are without option to not do so if its a "AltGr"-meta.
But what is the point of being this "pro" I know who it excludes, regular people.
Not being one of those, I still dont see a benefit. If we put the treshold at me, then that is fine and all for you smarter folk. That market is wast. Maybe its feasible, but importantly its _less so_.
Regular people for example dont understand stringing together alt with shift to produce third level modifier. It is less efficient, and it is alien. It doesnt work.
What does work normally however is pressing "a number of shoulders that you dont see"+one main keyboardbutton, and you have Alt+F4-ed what it was that you were doing.
F-ingMeta on shoulders is broken.
Or worse yet, to bait the trap "one shoulder that you dont see that is next to shift-shoulder"+Q to press escape, accidentally an end to what it was that you were doing.
Sorry @comradekingu & @_wb_ but I still don't understand how it works.
If I sumup, you have 2 Meta/AltGr, one on the main Keyboard, one on the shoulder.
To press F1, I need to press Meta + 1
My question is still the same.
In an SDL loop, I expect, when pressing F1, to get only SDLK_F1 event.
But I expect also to get some event when pressing any of the Shoulder (like we have SDLK_RSHIFT & SDLK_RCTRL on the Pandora).
So, either the Shoulder as Meta is configurable (like todays the nubs, that can be switch to Mouse / MButtons / Absolute by script), or there is something I don't understand.
(but sorry if it was explained somewhere in the multiple thread, there is just too much to read for me).
If you press L2(Meta) + 1 to get F1, I would expect SDL to show an SDLK_RMETA and SDLK_F1 event. The application will probably simply ignore the RMETA event because it is an event it is not listening for, so things will mostly work as expected.
Now, as far as I know, the number of game devices that actually have both F-keys and shoulder buttons is zero. PC-games may use F-keys, console games may use shoulder buttons, but I don't think there is any type of game that originally uses both the F-keys and the shoulder buttons.
Emulators? IIRC mednafen on PC uses F keys to enter configuration modes. Of course anyone who ports an emulator can change that, but with the Pyra being more able to run more powerful emulators without so much optimisation, it will mean that some emulator ports require more work than they otherwise could do.
Perhaps emulator authors could do something simple so they keyboard sticks in Fn-lock mode so that you can use the number row without having to go through the code and modify every keyboard event code. Or we could go with Kingu's soltution with an F-button key (I disfavour the word 'F-ing' by the way).
Or just drop F-keys. Like apple/google/lenovo is doing, its going to look dated in the future if they are printed.
And also quite wonky since F11 and F12 isnt on the same row. Put them on ASDF and they dont align with the number row.
My argument here is that advanced users, who have the need for them, can remember where F-keys are, even if they arent printed. 1 is F1, 2 is F2, and then F11 and F12.
For novice users, printing less useless information is better.
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.
