english/US keyboards dont do shift+ and something else+ to type [ ] and { }
Standard keyboards don't do <ANYTHING>+<something> to get "[" or "]". There aren't enough keys for dedicated [ and ] so we will NECCESSARILY have to put those (or if not those exact keys than some other "standard" keys) behind altgrfnmetamod combo. Standard english/US keyboards don't do altgrfnmetamod+<anything> to produce a single keycode either yet that's what we need to do. Your argument here is irrelevant.
And I addressed it already anyway, since we CANNOT have dedicated [ and ] (or if we can for those two keys, something else WILL suffer and you can just mentally swap in those keys in this argument and it'll mean the same thing) and we WILL need to put [ and ] on altgr keys, then if you want to stick as close to the English keyboard standard then it actually makes MORE sense to have "shift"+<whatever> to get as many of the standard English shifted keys as possible, even if <whatever> is itself an altgr key combo.
This is the problem of referencing "standard keyboards" it confuses the matter. There are ANSI keyboards, and there are ISO and JIS keyboards, the latter
two operate differently from the ANSI US/UK one. There are enough keys for
dedicated [ ] and { } like on a
US/UK keyboard.
They especially dont use fn to type the latter part of each. In no uncertain terms does any keyboard layout not mix fn with altGr
We're using AltGr and Fn interchangeable because whatever the Pyra's key is will in fact not really be either. It is not a full on hardware key like a standard Fn you find on a laptop, nor is it just a right alt modifier as the AltGr is on a full sized keyboard.
It is a "do the thing that needs to be done" key. If you are getting confused by this and cannot separate the AltGr of a full sized keyboard with what the Pandora NEEDS the key to do then I suggest you stop calling it that. This argument here is also irrelevant.
Then don't call it either. The behaviour of AltGr is different depending on which standard keyboard you are referencing. (US or Euro for simplicity of argument.) I call it a hack because its a hack.
There are no hardware interrupt keys on the pyra btw. Maybe you meant dedicated key, then see below.
altGr is a known key, and does something else when typed along with the combo described
As has been mentioned many, many times, the Pyra's AltGr key CANNOT UNDER EVERY CIRCUMSTANCE behave the same way as a full sized keyboard's AltGr.
There are a few cases where we may be able to map the keys correctly, and in those situations the algrfnmetamodwhateverwecallit key plus those combos can be made to spit out "right-alt"+"whatever", but for the vast majority of keys it will, definitely, need to be treated more as an Fn key, where pressing it in combo with another key changes the scan code.
It needs to be like that, it cannot be any other way. We can't, for example, press "altgr"+"U" and expect the software to realize that "right-alt"+"U" means "F8". No, when we press "altgr"+"U" it needs to output the F8 scancode. It can ALSO output some new scancode which is unique to the Pyra, an "altgrfnmetamodwhatever" scan code, but most software is going to ignore it. This argument is also irrelevant.
edit: In fact, this argument is just further evidence that we shouldn't call it AltGr, that ED made a mistake when he said he wanted one. He didn't know the technical details, and perhaps in theory it sounded nice, but the technical details are what are preventing it from being fully realized: accept the flaw, scrap that idea and use something else.
edit edit: More to the point, the Pyra WILL ALREADY HAVE AN ALTGR key. In every layout there has always been two Alt keys, one on the keyboard and one on the triggers. One of them will be left-alt, the other will be right-alt. The one that is right-alt will already behave identically to a standard full sized keyboard.
The only exception from how AltGr needs to be different, is in not having enough buttons on the letter row, putting the symbols here, albeit in
a uniform way, is less of a hack than spreading them all across the keyboard.
ED knows exactly what hes talking about, because he considers fn
to be a suboptimal solution. It is, even on regular keyboards, a hack to implement 1. dedicated hw on/off buttons 2. things regular keyboards dont
use fn for, because the desktop keyboards dont have one.
Talking about standards and then breaking them makes no sense
I disagree. Talking about standards and HOW WE CANNOT FOLLOW ANYTHING 100% and then providing examples of how we can follow a standard as closely as possible to avoid confusion makes perfect sense.
If trying for 100%, yes, that would be another matter entirely.
Thats not whats happening though. Whats happening is breaking every convention there is, only to maintain the one part that makes for no config in dosbox or qemu.
Those two aside, changing any convention to something decidedly non-standard creates problems for users. And unforeseen problems in other software.
Internationalization is also an area you cant make stuff up in, since it already exists. The way to do it isn't to have extra dedicated keys, its to have the same dedicated keys behave differently according to region. Before you get to touching anything, US international dead-keys should work.
Adhere as strongly to standard as possible, where standard is majority, or a combination of mass. Not new inventions under the cover of being functionally proven and known to work.
We MUST, absolutely, no question, without a single doubt, invent something new. There is no standard, none, zero, zilch, nada, nothing like this has ever existed in such a way that we can use. Period, no debate, absolute truth. Start with that. Can we agree to this? That there is no standard that we can apply one-to-one? If we can't agree to that then you are living in a world that I can't even imagine and the debate needs to end right now, we will never reach an agreement and the best thing is to just lay out the arguments side by side, independently, and let EvilDragon decide.
If you can agree with that, if you do see that there is no standard we can fully use, that we will need to invent something in order to get it to work, then take a closer look at what I've been saying.
My argument is that Grench's layout DOES adhere as closely to English keyboard layout standards as possible. He may have "{" tucked behind "shift"+"fn"+"J", but that's only because "[" is on "fn"+"J". "shift"+"[" is "{", so if "[" is "fn"+"J" then it MAKES SENSE AND ADHERES TO THE STANDARD that "shift"+"fn"+"J" be "{". If you do not agree that it makes sense then you will have to come up with a counter argument that doesn't depend on the artificial belief that we can't use "shift"+"fn" because "that combo doesn't exist on standard keyboards". Of course it doesn't exist, standard keyboards have enough keys.
A dedicated F-row key, that does only F-keys isn't new. It already exists on desktop keyboards with fewer keys. All 60% keyboards run some variation of this. Sometimes dedicated F-key modifier, but often called "Fn" mixing both mediakeys and F-keys. My argument is that with a F-row modifier key, and an AltGr-key, you don't confuse the two. And there are enough buttons to do so. Also there are enough keys to do dedicated hardware modifiers (brightness, power, power settings) If you are wondering where my hack is, its F-ing button+shoulders to be mediakeys. That way you know there isnt going to be any upsets with standard stuff at least.
Edit: On new dell laptops Alt+F4 doesnt close a window, that is Alt+Fn+F4. The reason being F4 is "skip forwards", because the mediabuttons are primary.
![dedicated [ ] and { }](https://pyra-handheld.com/boards/uploads/post-2326-0-41907700-1427028696.png){kind=link}