It's the keyboard layout.


Really no need to panic over this by making a mountain range out of an ant hill.
I agree, but some people can't get around the idea that the Pyra's "AltGr" is incapable of behaving the same as a full sized keyboard's AltGr. To get around the confusion and actually move the conversation forward we should stop calling it that. At least temporarily. If we want to revisit and go back to calling it AltGr in the future that's fine, but right now the confusion is seriously keeping us from having a proper discussion.The confusion is doubled when we have a "right-alt" which some people might take for an actual "standard full sized AltGr".
 
  • Like
Reactions: szr
Suggestion: let's for now call the modifiers-that-are-not-ctrl-shift-or-alt by their implementation. This gets rid of the ambiguity in the names. HWM for hardware or driver-level simulated hardware modifier (such as regular and pandora style Fn) and SWM for software modifier (such as AltGr and Meta). Whatever we will end up with should, in my opinion, be named only after we decide what it actually IS. Until then we can speak of the keys by their function. I bundled regular and simulated hardware modifiers because they work the same way from any application's point of view. We'd probably be talking about a simulated hardware modifier like pandora has.

So, WizardStan says we need a HWM to be able to produce all the scan codes on a full keyboard, because that's what applications expect the user has. I agree.

Saber says we don't need an additional SWM. I disagree. On the other hand, this is one thing that's quite easy to fix with custom key bindings, unless software ends up binding stuff to specifically keyboard right shift, in which case I'm screwed again :)
 
I don't understand why there's such a big deal about needing a HWM. There's what, who peices of broken software available that would be "fixed" by having a HWM and the right keymap? Why not just patch the broken software? With one SWM and a keymap that otherwise maps well, it should be a trivial task...
 
I don't understand why there's such a big deal about needing a HWM. There's what, who peices of broken software available that would be "fixed" by having a HWM and the right keymap? Why not just patch the broken software? With one SWM and a keymap that otherwise maps well, it should be a trivial task...
You're confused, sorry. We're not even talking about DosBox/QEMU issues here, this is straight up all the keys we can't fit: The F? keys, punctuation, etc...We can't have dedicated F1-F12 keys, they must be on modifiers. They can't be behind SWM, all software, not just two, expects the keycode for "F1" when it is waiting for you to press "F1": it isn't expecting "AltGr"+"Q" (from Grench's layout). Hence the need for a HWM, this key combo "HWM"+"Q" would actually produce the correct "F1" scancode. This doesn't just apply to two pieces of software, this applies to basically everything, and not just the F? keys, what about the punctuation we can't fit on dedicated keys, the "[", "]", and "\"? Regardless of the layout something needs to go behind a key combo, we don't have enough keys for a full keyboard, so we need this HWM key, whatever we end up calling it, that modifies the keypress to produce the expected scan code, similar to how it's done on the Pandora.

In theory we could just use SWM key combos, "AltGr"+"Q" really does produce "right-alt"+"Q" and then we modify software as needed so it accepts that instead of F1, but we're seriously opening ourselves up to problems, I would think.
 
No, you're confused. Not a lot of software expects F1 to have a specific scancode. On my pandora, I just remapped shift-M to be F1 with xmodmap. It behaves as expected with all programs I tried.
 
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.
 
Last edited by a moderator:
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.
There is usually an option to change that behavior in the BIOS/Firmware, to set whether or not the F-keys are primary or not.
 
Then don't call it either.
That is what I've been saying! Christ on a cracker it's like you haven't read anything.
Whats happening is breaking every convention there is, only to maintain the one part that makes for no config in dosbox or qemu.
Ok. Like I thought, you're thought process on this is so alien to me that even after explaining, at great length, what Grench is trying to achieve, you still come back to the same point, which means that I am entirely incapable of making you see the point. Whether you agree or not is moot, we'll just be going in circles forever. I propose a split in the conversation: you take your keyboard idea to one thread and Grench takes his keyboard idea to another thread, and EvilDragon can take a look at the benefits of either. That way you can stay out of the discussion you clearly don't understand. This conversation has been pushing against the same wall for 4 pages now.
 
... We are then free to label that "magic-do-the-thing" key in the lower right (usually they're lower right, has anyone put it on the left? Whatever) whatever we want.


Call it mod, or Fn. Not AltGr because we've already established that it cannot behave like a keyboard AltGr, we already have an AltGr in the form of a "right-alt" key, and some people are getting confused over it. I also wouldn't recommend "meta" because that might get confused with ctrl. And it seems some people get confused with the existing "Fn" keys on laptops.


How about we stick with "Mod"? Does that key already exist in a way that would cause confusion? That properly describes what it does, it "modifies" whatever you're hitting next in some way, the way of which is typically described on the keyboard itself.
I am looking at a keyboard right now that has "SYM" in the bottom left next to shift.  In this browser it just makes a space, however in software where it works it launches a window thing with various symbols and non-English characters.  This is an Android device, so this may be built into the OS, or be device specific, I don't know.  (I also have an "OK" key I have never used.)

The name of the key doesn't matter as long as it is easy to understand.  Put a gear, or tools, or a partially built wall if inconsistincies because of a name is bugging everyone.  Mod, Build, Char, Etc might all work for names.  I have mentioned this elsewhere before, but a Pyra symbol in the same color as the characters it produces are marked in might work, or maybe a sideways (turned 90 degrees) Pyra symbol.  Hell, go half and half and label it "...".  Or "Other" or put a frowny face on it.  But seriously, as long as it makes sense to most people and is in the manual the name/marking doesn't matter, and ED will call it what he wants.


 
Last edited by a moderator:
But seriously, as long as it makes sense to most people and is in the manual the name/marking doesn't matter, and ED will call it what he wants.
That's what I've been trying to say. We need to get past this "you can't use it like that, it's an AltGr button and needs to behave as such" argument, just call it "foobar" for now and figure out what to call it later.
 
  • Like
Reactions: szr
In my mind it is now the FU key.

So now that everyone agrees that we will call it something, possibly not AltGr, can we all just put that aside for now and use whatever names individuals like so that the actual keyboard layout can continue to be refined?  I would like to know if ED is ok with the direction Grench went, or if it needs to be closer to Saber's in the first post.

Saber, would you mind implementing what you like from Grench's layout into yours if it isn't much work, or you have time?  I think the way forward is combining what ED likes and the things that were proposed that most agree might fix the issues (in other words, work together).  I won't really be offering suggestions this round because there are too many little things I don't know enough about, or have time to research.  I am good at pointing out the problems I see, even if no one else sees a problem, so I will probably continue to do that.
 
Dedicated Escape key, which exits or closes some software, might be too close to select which will probably be used to do things inside certain software, such as emulators.  If someone is trying to do the screen warp in Link's Awakening and hits Escape by accident, and that closes the emu, they may lose their progress.
 
Dedicated Escape key, which exits or closes some software, might be too close to select which will probably be used to do things inside certain software, such as emulators.  If someone is trying to do the screen warp in Link's Awakening and hits Escape by accident, and that closes the emu, they may lose their progress.
Perhaps, but did you ever hit the Menu key accidently when you meant to press Select? Has anyone but on only the rarest occasion? There does look to be plenty of clearance between the two keys.

It's fine though. I offered the dedicated Escape versions as auxiliary layouts to the main ones. Wanted to explore options is all.  :)

We could put Escape between Start and Select. They'd be columned as Start, Escape, and Select. Just an idea.
 
Last edited by a moderator:
BzRINNAIYAE8lcM.jpg


+

550cat_l.jpg


Solved, next problem?
 
About sabers layout in firstpost: Digitalized by wb

How i see the goals covered

  • The keyboard should be standard enough to be used by every normal user.
I have shown this layout to people without saying anything, nor showing a manual, and it never fails to confuse, no matter the level of technical knowledge.

  • It should be balanced between text typing and coding
Ok.

  • It should have most of the keys a normal keyboard has (i.e. Pandora keyboard has issues with DosBox).
It could have more keys. It could have more standard keys.

  • The 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)
Absolutely the weakest point. It fails, and the people who need it not to notice right away. Dealbreaker.

  • We 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)
Ok, but Fn-ish behavior is used, not AltGr. The alternative is doing 4 per key on number row and colouring the numbers to signify double-duty since it can be two modifiers. One for position, the other for colour.

  • The most-used keys should get the best positions
, and . are the keys that arent decided by qwerty. Putting them at extreme bottom left is as bad as it gets.

                  What do I like about it

  • Home end pageup pagedown are in positions correlating to function, best possible integration.
  • numberrow up top
  • Powerbutton nice and sentral, easy to find.
  • Space is close to shift
  • No contamination of hardware buttons area.
                 What dont i like

  • Its not evident what Br+ and Br- does. Even if you know that its brightness.
  • BXYA is an orientation that is now almost extinct. It is also activly confusing since two of the most used have these same letters in other orientation.
  • slalom-typing on every sentence is very inefficient. Dot isnt close to enter, comma isnt close to space. Enter isnt close to dot
  • It only features enough usable positions for one alphabet, the english one, excluding everyone else.
  • select start  should translate to  select above start, allthough this is not a huge issue. I think thats how the old arcades were too.
  • F11 and F12 could be just one de-tour, now its two.
  • Visual clutter
  • No dedicated key for <> (subjective preference)
  • + and - is duplicated on the keyboard part, makes for potential confusion as to how input + and - is. Doesnt help that the real + and - is far away from + and - on a regular keyboard.
What i cannot tell is

  • There are 3 alts+ one hidden alt at the start key.
  • Something called AltGr is consistently on the left shoulder.
I would prefer if it was on the right. Same as regular keyboard, same as name, same as what people are used to.

  • A connection between where the imprints are on the keys (that they follow an order) along with where to find the modifiers.
Put this here since it has to do with the Alt situation.

  • The keys are very long and flat, so printing something above the other on the same key doesnt work.
Put this here since it is derived from above.

  • What does R.Alt do?
If AltGr does the nonstandard symbols on the keys. Does R.Alt do the same, only in the standard euro way in the positions of the decided keymap?

Which one of them does third level modifier on the number-keys?

  • Insert and delete are swapped compared to a desktop keyboard.
I dont see a benefit to that, would like to get some insight there. Is it to get delete farther away from the typing space? The dedicated escape is just as close.

And the alternative suggestion is to put it on a typing-button (Q) triggered with a shoulder (?) That sounds like a trap.

  • No apparent connection between 4G and usb.
These are both on one button on one of the proposals. Some models might ship without 4G, making it strange to have it on the layout for those devices.
 
Last edited by a moderator:
Dedicated Escape key, which exits or closes some software, might be too close to select which will probably be used to do things inside certain software, such as emulators.  If someone is trying to do the screen warp in Link's Awakening and hits Escape by accident, and that closes the emu, they may lose their progress.
Perhaps, but did you ever hit the Menu key accidently when you meant to press Select? Has anyone but on only the rarest occasion? There does look to be plenty of clearance between the two keys.

It's fine though. I offered the dedicated Escape versions as auxiliary layouts to the main ones. Wanted to explore options is all.  :)

We could put Escape between Start and Select. They'd be columned as Start, Escape, and Select. Just an idea.
I just want to be clear, if it doesn't get in the way of other keys I feel are more important, I would really like a dedicated escape key, regardless of location.  I am pretty sure you are correct about that being a safe place, and it isn't too far away from the main keyboard for me.  Additionally it is out of the way for those who fear putting destructive keys too close to other things.
 
What you are describing does happen, and you would remember it a lot more if it actually closed what you were doing.

From the days of windows, going to desktop by pressing the superbutton in between left ctrl and alt when playing games got old quick.

Things like this only have to happen once for people to remember it well, especially if you lose work over it.

The leftmost key on the power-column is a good placement for escape, it is out of the way, in similar fashion to where you are used to fiding it, up and to the left.

Stringing together ctrl+alt and typing 5 6 and 7 is no longer possible quickly if there is an escape in the way. You lose an ok way of doing dead-keys that way.
 
Last edited by a moderator:
  • Like
Reactions: szr
The squiggly symbol is called Section Sign. On the Pandora, the Yen occupied the place where § is now in the layout and was known humorously as the "remap key". Section Sign will likely serve the same purpose. 
Huh, I wouldn't know I guess.  Hopefully it will be useful for the Pyra :) .

Anyways, hope you and others like them in a preliminary sort of way.   :)
I do think you have a nice layout in general, and I appreciate your taking the time to do modifications based on community input :) .  It's looking extremely polished.

I'm looking at one of the dedicated Esc maps you have...  http://i.imgur.com/p95W4GM.png

I really like this, except that I feel like you moved ", ', ?, and / around worse from an earlier layout.  I would have kept ' and " on A and S, / and ? on Z and X, respectively.  (Alternatively, you could do ? and / on Z and X, which would make /= an easier combo ;) .)  This way things are "closer" to each other (horizontal relationships are less jarring than vertical relationships, IMO).

For the same reasons, I would also want backtick and forwardtick together, and \ and | next to each other (horizontally).  But I don't use either ticks very much, and I don't often pipe things, so it's not that important for me.  It does make certain keys harder to reach, which may not be as happy for some people.  And maybe the changes have been made for certain other reasons, which I missed in the intervening discussion...

Also for people who are worried about escape being too close to something, just change what it does in the given program.
 
Back
Top