True. But of course you already don't have cursor movement and home/end, so text editing is tricky anyway if you want to consider the gaming buttons exclusively as gaming buttons. I don't think it's a problem in practice, because most games that require text input don't require text input mid-game: if it's just something like multiplayer chat or highscore name entering, then the game will typically be in some kind of "text entry" mode, where the game actions don't work anyway.
Just because game actions don't work in that mode doesn't necessarily mean that the text editing effects of those keys would be restored. Also, while the other keys are often used for text editing, backspace is most frequently used during text entry, so it has a slightly different function that I feel should not be separated from the main keyboard.
Good point, the distinction between text editing and text entry. But of course the two extra game buttons don't have to be used for game actions; e.g. Pandora games would not use them by default.
I suppose that depends how it's implemented... One of the issues that came up with pandora though was that the nubs were treated as different joystick devices and the buttons were not treated as part of the joystick devices at all. In some games which were designed to use either joystick or keyboard control (but not both at the same time) this made control mapping... tricky, especially if it was closed source software running through something like DosBox. To avoid such an issue it makes sense to offer an input mode where the nubs and all the gaming buttons all act as a single joypad device. Switching to and from such a mode would probably have to be done on program start and exit, like switching the nubs to joystick mode is done now on the Pandora. That being the case those keys would be unavailable for the duration of that time regardless of whether the game actually uses the entire set of buttons or not.
Grench's idea is to make an Fn lock readily available for exactly that purpose: enter a game, turn on the Fn lock, and not only do you get the common 1-0 keys but also the F1-F12 keys that a lot of games use. There's no need to do anything for either of those. It is arguably superior to having the numbers on the default row and the Fx keys on the Fn row, at least for gaming, because games will frequently use both and having them on different meta layers would mean extra keystrokes: by having them on the same meta layer there's no such requirement, just a lock and use them all.
Cannot be achieved. Period. There is no way to make regular typing in regular ways a thing, the Pyra keyboard is not regular and should not be viewed as such: compromises need to happen. Arguing against one particular compromise because it "isn't regular" is a strawman.
Thank you - I'm glad someone actually understands what I'm trying to achieve with the numbers on Fn idea.
I had figured comradekingu would have been jumping for joy in enthusiastic support of this one that finally gets him true P+1 and L+2 Germanic language support without compromise:
You're the one throwing considerations out. Literally, that is exactly what you've done. Not in so many words, but basically "this is not 'regular' therefore it is not worth considering".Grench has an idea, he's presented arguments as to why he thinks his idea is good, and those arguments are sound. You've dismissed it because it is different.
No it doesn't. By definition a compromise is a tradeoff. A compromise will be better in some respect but it will necessarily be worse in a different respect. If there weren't something lost then it wouldn't be a compromise, it would just be a straight up improvement. A good compromise is one where the gains are deemed to be worth the losses.
The Pandora's Fn key wasn't hardware either, it just emulated a hardware key by changing things at the kernel level. They Pyra will need to do basically the same thing.
Thanks, slaeshjagI wonder if I could add this functionality to inputty. Would make it possible to add chording support and other stuff to any input devices
Except that of course that unlike the fn key on the Pandora it will also need to generate an input event of its own to be used on a shoulder button.
