It's the keyboard layout.

[szr]

My position/reasoning about the DosBox / US-QWERTY symbol pairs is as follows:

1. The software issues with DosBox are just software issues and can be solved.

2. Still, I think it makes sense to let the Pyra keyboard resemble one standard as closely as possible. US-QWERTY is a natural standard.

3. Shift+Meta is certainly possible (we want Shift-F-keys for example), but it is slightly less convenient than just one modifier.

4. Because of point 3, I prefer to have {}|:"?_+~<>!@#$%^&*() behind only one modifier (Shift if the unshifted key is available as a dedicated key, Meta otherwise), but because of point 2, I want the shifted symbols near the unshifted symbols so they still form pairs in a systematic way.

5. Duplicating the labels for the shifted symbols looks ugly and weird, and it feels wrong. There is nothing wrong with making Shift+/;'[]`-= produce the corresponding shifted symbols by default though.

I made yet another layout proposal in this spirit:

http://www.keyboard-layout-editor.com/#/layouts/16c6d036ba4e34ef2b8e3008c3c8cc89

I just have a couple small questions about this layout.

1) Where you say "Shift+Shift: Caps Lock", would this invoke the real Caps-Lock key that exists on most full-size keyboards as a distinct key (and whose behavior differs from simply holding down shift) or is it simply making shift sticky? I think the former would be better as there doesn't appear to be a a caps-lock anywhere else. Perhaps Shift+Shift = real Caps-Lock key, and perhaps Meta+Shift+Shift = sticky Shift? Or would the latter be too strenuous?

2) What exactly does "eta lock" mean, where you wrote "Meta+Meta: eta Lock" ?

3) I really like the idea of the lid closed acting as Super being held down, allowing for media controls as mentioned in the layout. My only question is, would this cause the battery to drain quicker, as it would be like holding a key down for a long time. I'm not sure if that uses any more power than with no keys being held, or if the extra usage would simply be very negligible.

4) This is a very small thing. I noticed that you have PrtScn and SysRq as separate keys, and I wonder if that really is needed. On most keyboards that I've seen, the latter is the Shift (or is it Ctrl?) + the former. Maybe have the key labeled SysRq be Pause/Break instead, and maybe meta + that key be Scroll Lock?

Also, is SysRq actually used by something? I've noticed many layouts posted seem to put it in such upfront positions, so maybe there is something I don't know about regarding it.

Thanks.

 

[WizardStan]

You have every bit of functionality lumping thirdlevelshift and pressing F-keys together have

There. Right there. That thing that you just said, the functionality that you are describing in that exact sentence is precisely what everyone else is referring to as "fn-like" (or whatever their exact words are, everyone else understands what we're all talking about when we say whatever it is that is said, except for you)

with none of the problems it causes.

Except that there ARE problems. The problems have been explained to you at length but I will summarize, once again, the two that I feel best represent the difficulty (I had a third one but as soon as I started typing I forgot what it was. It'll come back to me eventually.)1) You are using a key that a lot of people are familiar with in a way that they are unfamiliar with. This has the potential to cause confusion. This is distinctly different from doing things in a non-standard way out of necessity, or inventing a new standard where one never existed before: this is something that already exists, and you are intentionally doing it differently.

2) It is strictly limiting: by having a specific AltGr key you are stripping away the users ability to use a keymap that relies on a REAL AltGr (that is, treat R_ALT as a soft mod) without causing confusion.

Both of these problems (and in fact all problems that you're failing to address with it) completely disappear if you simply call it anything other than AltGr. Seriously. That's it, that's all you need to do. Stop calling it AltGr: call it Fn; call it Meta; call it Sym; call it quijibo for all anyone cares; just stop pretending that it is analogous to AltGr, because it isn't and it's extremely disingenuous the way you try and convince people that it is.

You literally gain nothing by insisting that it is AltGr vs ANY OTHER NAME, and lose a lot through potential confusion. Seriously, to quote you on the subject of doing things in non-standard ways, "who does that?"

 

[Grench]

This issue is NOT just with DosBox. It is ANY software that addresses the keyboard as a physical array of hardware keys. DosBox is simply the easiest to point to example.

 You cannot expect to do it with a simple keymap to keymap lookup table... Instead you need to monitor Key up/down events and then translate these events into a set of events that would happen if you were using a "real" US keyboard.

For example the user on some custom keyboard does some vulcan nerve pinch combination of key presses, the keyboard translation layer recognised this 3 key combo (giving time to ensure the first two key down keys aren't the actual key - the user might press shift then P then altGr the altGr might land a few milliseconds late) The translation layer would then send for example alt and N (or whatever) keys down events that a "real" keyboard would generate, to the application...

The reason its not been implemented is probably because no one who can, could be bothered to waste anymore time on it that just a simple keymap to keymap lookup table...

This is one reason (of many reasons) why you should NEVER use low level hardware values for things like keys (or anything else)

Its a pita yes but eminently possible - and certainly no reason to hobble a keyboard at a hardware level.

Which is exactly why we need to maintain the US standard keyboard character and symbol pairs. So the keyboard works -properly- at a hardware level, regardless of the application used on it. We cannot 'hobble' it by arbitrarily breaking these pairs to randomly salt them over the layout.

 

[_jr_]

I was under the impression that the so called dosbox compatibility issue simply cannot be solved in dosbox alone (unless you want to introduce additional latency). AFAIK at least for some applications it is neccessary to have the shift down happen before the actual key press.

 

[_wb_]

My position/reasoning about the DosBox / US-QWERTY symbol pairs is as follows:

1. The software issues with DosBox are just software issues and can be solved.

2. Still, I think it makes sense to let the Pyra keyboard resemble one standard as closely as possible. US-QWERTY is a natural standard.

3. Shift+Meta is certainly possible (we want Shift-F-keys for example), but it is slightly less convenient than just one modifier.

4. Because of point 3, I prefer to have {}|:"?_+~<>!@#$%^&*() behind only one modifier (Shift if the unshifted key is available as a dedicated key, Meta otherwise), but because of point 2, I want the shifted symbols near the unshifted symbols so they still form pairs in a systematic way.

5. Duplicating the labels for the shifted symbols looks ugly and weird, and it feels wrong. There is nothing wrong with making Shift+/;'[]`-= produce the corresponding shifted symbols by default though.

I made yet another layout proposal in this spirit:

http://www.keyboard-layout-editor.com/#/layouts/16c6d036ba4e34ef2b8e3008c3c8cc89

I just have a couple small questions about this layout.

1) Where you say "Shift+Shift: Caps Lock", would this invoke the real Caps-Lock key that exists on most full-size keyboards as a distinct key (and whose behavior differs from simply holding down shift) or is it simply making shift sticky? I think the former would be better as there doesn't appear to be a a caps-lock anywhere else. Perhaps Shift+Shift = real Caps-Lock key, and perhaps Meta+Shift+Shift = sticky Shift? Or would the latter be too strenuous?

2) What exactly does "eta lock" mean, where you wrote "Meta+Meta: eta Lock" ?

3) I really like the idea of the lid closed acting as Super being held down, allowing for media controls as mentioned in the layout. My only question is, would this cause the battery to drain quicker, as it would be like holding a key down for a long time. I'm not sure if that uses any more power than with no keys being held, or if the extra usage would simply be very negligible.

4) This is a very small thing. I noticed that you have PrtScn and SysRq as separate keys, and I wonder if that really is needed. On most keyboards that I've seen, the latter is the Shift (or is it Ctrl?) + the former. Maybe have the key labeled SysRq be Pause/Break instead, and maybe meta + that key be Scroll Lock?

Also, is SysRq actually used by something? I've noticed many layouts posted seem to put it in such upfront positions, so maybe there is something I don't know about regarding it.

Thanks.

1) I don't actually use Caps Lock myself, ever, nor do I use Shift Lock, ever. I DON'T UNDERSTAND WHY ANYONE WOULD NEED IT EXCEPT FOR SHOUTING. I would propose to let Shift+Shift be a user-configurable action: it could do either nothing at all, Caps Lock, or Shift Lock, or even something entirely different like Compose or whatever.

2) Meta+Meta could be Meta Lock. Potentially useful if you're using an application that uses the F-keys a lot, for example. Again, could just be a user-configurable thing.

3) No, this would not cause the battery to drain. Holding down a button does not consume any noticeable power. The only thing that consumes a bit of power are input events (because they cause interrupts that keep the cpu from sleeping), so e.g. continuously moving the mouse or the nubs would cause power consumption to go a bit up (you can check this on your Pandora if you want). Keys only produce two events though: key down, and key up. This means holding down a button does not keep producing events by itself (although of course software could be programmed to let keys auto-repeat while held down, but those are timers set by software, not by the keyboard itself). So no reason to worry about this.

4) SysRq is used as the Magic SysRq key in Linux, but I guess it does not really need to be explicitly labeled, since people who can remember Magic SysRq combos can surely also remember the position of an unlabeled SysRq key somewhere. So yes, Scroll Lock or Pause could be added instead. None of those keys are really important though.

By the way, here is yet another of my proposals (sorry about the proposal spam), it's called "_wb_ international" in the big comparison table:

http://www.keyboard-layout-editor.com/#/layouts/01192fa1799361f7066da5897b76fb89

 

[comradekingu]

You have every bit of functionality lumping thirdlevelshift and pressing F-keys together have

There. Right there. That thing that you just said, the functionality that you are describing in that exact sentence is precisely what everyone else is referring to as "fn-like" (or whatever their exact words are, everyone else understands what we're all talking about when we say whatever it is that is said, except for you)

I know why you are confused, and if you stop clutching to your belief by quoting me out of context, you will see both sides. Im not saying hack-like is different from hack-like, im saying its different from thirdlevelshift AltGr.

with none of the problems it causes.

Except that there ARE problems. The problems have been explained to you at length but I will summarize, once again, the two that I feel best represent the difficulty (I had a third one but as soon as I started typing I forgot what it was. It'll come back to me eventually.)
1) You are using a key that a lot of people are familiar with in a way that they are unfamiliar with. This has the potential to cause confusion. This is distinctly different from doing things in a non-standard way out of necessity, or inventing a new standard where one never existed before: this is something that already exists, and you are intentionally doing it differently.

Again out of context. It here refers to hack-like way of doing it. None of those problems, because they are avoided.

I am using AltGr. Everyone does this, except for anglo-people. Not perfect, but lets look at the alternative. Which is to lump what really is shiftmods from other buttons with thirdlevelshift on letters, together with Fn-like F-keys. Hack the planet!

Nobody does that. Your argument is brilliant, only its the other way around. Using a key a lot of people are familiar with, Meta, from old keyboards, something that never was a shift-type mod, to do both shift-type modifier and an FN-like behavior. Only on keyboard where there is _no other alternative_ will you find anything similar. Trying to implement more than you can fit gets ugly fast. Picking ugliness when there is an option is not only confusing, its confusing in itself.

2) It is strictly limiting: by having a specific AltGr key you are stripping away the users ability to use a keymap that relies on a REAL AltGr (that is, treat R_ALT as a soft mod) without causing confusion.


Both of these problems (and in fact all problems that you're failing to address with it) completely disappear if you simply call it anything other than AltGr. Seriously. That's it, that's all you need to do. Stop calling it AltGr: call it Fn; call it Meta; call it Sym; call it quijibo for all anyone cares; just stop pretending that it is analogous to AltGr, because it isn't and it's extremely disingenuous the way you try and convince people that it is.


You literally gain nothing by insisting that it is AltGr vs ANY OTHER NAME, and lose a lot through potential confusion. Seriously, to quote you on the subject of doing things in non-standard ways, "who does that?"

 

[szr]

1) I don't actually use Caps Lock myself, ever, nor do I use Shift Lock, ever. I DON'T UNDERSTAND WHY ANYONE WOULD NEED IT EXCEPT FOR SHOUTING. I would propose to let Shift+Shift be a user-configurable action: it could do either nothing at all, Caps Lock, or Shift Lock, or even something entirely different like Compose or whatever.

2) Meta+Meta could be Meta Lock. Potentially useful if you're using an application that uses the F-keys a lot, for example. Again, could just be a user-configurable thing.

3) No, this would not cause the battery to drain. Holding down a button does not consume any noticeable power. The only thing that consumes a bit of power are input events (because they cause interrupts that keep the cpu from sleeping), so e.g. continuously moving the mouse or the nubs would cause power consumption to go a bit up (you can check this on your Pandora if you want). Keys only produce two events though: key down, and key up. This means holding down a button does not keep producing events by itself (although of course software could be programmed to let keys auto-repeat while held down, but those are timers set by software, not by the keyboard itself). So no reason to worry about this.

4) SysRq is used as the Magic SysRq key in Linux, but I guess it does not really need to be explicitly labeled, since people who can remember Magic SysRq combos can surely also remember the position of an unlabeled SysRq key somewhere. So yes, Scroll Lock or Pause could be added instead. None of those keys are really important though.

By the way, here is yet another of my proposals (sorry about the proposal spam), it's called "_wb_ international" in the big comparison table:

http://www.keyboard-layout-editor.com/#/layouts/01192fa1799361f7066da5897b76fb89

1) I've never seen a keyboard with a Shift-lock before (not counting onscreen virtual keyboards on smart phones and tablets), though I can definitely see that being useful sometimes (separate from Caps-Lock which only inverts capitalization) on a portable computer system such as this. Same goes perhaps for Alt and Ctrl lock, if that is to be a thing too.

2) I feel rather stupid for not realizing that "eta" was a typo, where the "M" was left off. I guess I read it as "etc" originally which made me wonder what it actually referred to.

3) Thank you for that explanation. Yes it makes total sense to me about key down/up.

4) I totally forgot the Megic SysRq key existed. Or how useful it can be. Thanks for that link. I really need to brush up on that.

Thanks.

 

[Grench]

By the way, here is yet another of my proposals (sorry about the proposal spam), it's called "_wb_ international" in the big comparison table:

http://www.keyboard-layout-editor.com/#/layouts/01192fa1799361f7066da5897b76fb89

You are getting a lot closer to a usable reality with that one.

Good:

Key pairs from the US ANSI keyboard are retained.

I don't see any diacritics. That layout would work for German and French, but not Spanish. That may be OK.

Not so good:

Shift and Meta are both left hand driven - which handicaps using the left side of the layout's Fn+key set.

Bad:

Positions of symbol keys are strewn around a lot. Somewhat unavoidable. I could live with it.

Overall, MUCH better than your earlier proposals.

 

[MrConfusion]

Edit: So what would i do if i wanted to play a dos game that required all characters. I would plug in a keyboard.

This would require me to be at home, but ok, lets consider the option.  The option is not being able to type non-english, on the go, which is what the use-case and the userbase wants to do.

The real answer is hacking hacky software back into shape, you only need at worst one level of arbitration to do it.

Or making a keymat for all the broken-software-loving english people.

A bit of an exaggeration, this "not being able to type non-english thing"?

Late 80s home computers came in any locale as long as it was US and the schoolwork done with them, then printed and approved and graded was not insignificant... For international symbols its convenience we're talking about here, not lifelines...

A cleansing for DosBox, which is not the pos broken software I sense you are implying it is :

Hacking the hacky software gets repetitive and tedious real fast if you end up hacking because you originally hacked up something because you figured it would be a cool hack and it turned out to be just hacky.

There is risk of that happening here, but that did not happen in Dosbox. Software is targeted to an environment - we cannot reprimand the dosbox people for not guessing someone would make a mess of a de facto layout standard. It's not broken. Neither (at least in unix) does it directly hook to HW keyboard - it listens to SDL. It has to listen to keydown and up, because DOS reports them to apps running on it. SDL benefits in some ways from reading scancodes on the Pandora. In case of Dosbox it might or might not - I dunno.

Either way there is no hack gone haywire here, not in any layer, just people having done the right things combining to unexpected results.

Dont call an aspect of dosbox hacky before you actually read the source - the mapper is actually quite beautiful even in OO terms! There definitely are hacks in dosbox but this part just aint it!

I guess the lesson to learn, if any, is this: if you want to easily "leech" desktop software to your palmtop, you better aim to such a level of transparency that the palmtop behaves pretty much exactly like the desktop. The Pandora opted not to in the sake of ease of use. Then there's a cost in porting.

About those international keys...

Others have already suggested reserving Fns of some keys (3-4 would already cover a significant portion of Europe...) for national symbols. I think same should be applied to every currency (other than the dollar sign... imho...). Seriously it cannot be a dealbreaker to not have the exact Å staring at you from a plastic button. Just denote these with flag symbols with roman numerals or whatever, and stick a bitcoin logo to one of them, maybe, and make a little UI selector that allows the user to pick a country specific set. Anyone actually using them should get used to it pretty easily...

Custom locale specific keymats is the way Samsung would go, but that causes new issues and requires even more support from coders - not a good idea for this project.

And bringing the idea of using desktop keyboards to this equation is (I hope) a bad joke: plenty of people have asked me why I didn't just get an Asus Transformer or Surface... external keyboard is no option, just like a mouse is no option. Its a Palmtop, a PDA, it's not supposed to look like a USB hub someone stuck an LCD screen to... ;-)

 

[comradekingu]

I believe it says non-english.

They are not international symbols, they are letters.

Dosbox can be configured to use a lot of other things than US layout. Thats built in and described in the manual. 

Broken software otoh is an extremely marginal thing. Whatever the case may be, there isnt enough care for the issue in dosbox, because none of the games require it.

Or so wally said, hes the one porting the games for it, i dont know.

A hack would be to translate the input above the layer the software runs in.

The pandora had no choice but to be a toy keyboard.

Not having an Å is a dealbreaker, yes, you have understood how letters work. Same with any other, and they are in the exact same place.

Only dedicated keys are dedicated keys.

There is zero coding-issue in a straight swap from for example UK layout to Norwegian. There is zero usability issue too, because the buttons are the same. You can change them to be convenient, but then that is the issue.

Palm and PDAs went out of business for a reason. Make the keyboard look like a keyboard and you cater to the market that exists today.

 

[MrConfusion]

By the way, here is yet another of my proposals (sorry about the proposal spam), it's called "_wb_ international" in the big comparison table:

http://www.keyboard-layout-editor.com/#/layouts/01192fa1799361f7066da5897b76fb89

At a glance: Quite close to what I use, except pressing left diamond+shift might strain fingers like Fn+space did in default Pandora setup? Are triggers on the same side easy to press simultaneously?

If this gets chosen I'll be doing at least one swap: diamond+shift to between nubs like I got them now. I'm typing using that central "thumbing area" right now simply because the shoulder buttons are clicky and I got sleeping kids I don't want to wake next to me. Trust me - my hands are average sized or even smallish for an adult male and this works well, try it on you Pandora?

Edit: Do you have a justification for not "aping" the "general location" of some keys from regular keyboards? For example =+ one is at last row, not first (qwerty) one?

 

[MrConfusion]

I believe it says non-english.

They are not international symbols, they are letters.

Whoopsee, yeah, I edited that to "non-english" thanks.

As for symbols: thats semantics, but to clarify: I mean everything visible a keyboard can produce, everything that is not a blank space, so a-z its all just symbols to me as are () and co..

Additions:

DOS games using scancodes totally ignored localisations, big titles were switched to new layouts when translated. Arguably this just made things worse. Localizing dosbox does work if you insist on using WordPerfect in 2015...

This is an example of explicit support needed when one scancode does several things over different areas. Things haven't changed. But after some further thinking the Pyra could probably do away with the problem simply by varying the keymat only for national symbols and nothing else. As long as scancodes for keys used by emus would be fixed there would be no more issues.

I don't see everything as straightforward as you do (hmmm... or maybe it's the other way around...), but since our comments have moved so far from subject matter I'll just shut up about this stuff now - what needs to be said is said and then some.

 

[bzar]

Late 80s home computers came in any locale as long as it was US and the schoolwork done with them, then printed and approved and graded was not insignificant... For international symbols its convenience we're talking about here, not lifelines...

 

[MrConfusion]

Late 80s home computers came in any locale as long as it was US...

<images of localized c64 and amiga>

Point well made, after a quick calculation my C64 was bought in '84 - no scands, but not late either.

 

[_wb_]

Here is a somewhat improved version of _wb_ international ("_wb_ intl 2") in the big table:
http://www.keyboard-layout-editor.com/#/layouts/7154da244376c7bc3db1fa65ca878431
 
The Polish lost their Ł, but they can map £ to Ł or something.
The French lost their dedicated Πkey, but I think they can live with that (they don't have it on their own keyboards either, typically).
Other than that, I added an explicit dead grave and tilde at Meta+A (in addition to the non-dead backtick and tilde at Meta+I).
The ASCII punctuation symbols should be closer to their normal US-QWERTY location now; I gave up on keeping all vowels free for Meta remapping since almost nobody would actually need to remap anything -- the point of the proposal is to have lots of international support out of the box, so to speak.
 
 

By the way, here is yet another of my proposals (sorry about the proposal spam), it's called "_wb_ international" in the big comparison table:
http://www.keyboard-layout-editor.com/#/layouts/01192fa1799361f7066da5897b76fb89

You are getting a lot closer to a usable reality with that one.

Good:
Key pairs from the US ANSI keyboard are retained.
I don't see any diacritics. That layout would work for German and French, but not Spanish. That may be OK.

Thanks!
 
The diacritics are marked using the symbol ◌, e.g. Meta+" for dead umlaut, Meta+' for dead acute, Meta+, for dead cedilla/ogonek, Meta+> for dead circumflex, and so on. There are four dead diacritic keys behind Meta (at ' A , .), each with an unshifted dead diacritic (acute grave cedilla dot) and a shifted one (umlaut tilde caron circumflex), for a total of eight dead diacritics.
 
In addition, precomposed versions of the most important accented letters are directly available: ñ for Spanish (also ¿¡ by the way), éèàç for French, üöä for German, etc.
All dedicated special letter keys found on Scandinavian, German, French, Spanish and Portuguese keyboards are included. Italian and Dutch don't really need extra letters but they do need some diacritics (though they would benefit from the French precomposed letters). Turkish and many Eastern European languages are covered by the selection of diacritics and they can use some of the precomposed letters (e.g. ö ü ç for Turkish), but for more efficiency they probably want to put their extra letters on dedicated Meta keys instead of using the dead diacritic method (e.g. for ğ ı ş in Turkish).
 

Not so good:
Shift and Meta are both left hand driven - which handicaps using the left side of the layout's Fn+key set.

Bad:
Positions of symbol keys are strewn around a lot. Somewhat unavoidable. I could live with it.

Overall, MUCH better than your earlier proposals.

Shift and Meta are on the left and all of the ASCII punctuation symbols are on the right. This is intentional: it means that those combinations should be easy, even if you don't use the shoulder modifiers. I would still make at least Meta sticky by default, so that also the Meta-symbols on the left are easy to do even if you don't use the shoulder buttons.

I hope the location of the ASCII symbols makes more sense now, compared to the previous version. Also I think the location of the language-specific symbols makes more sense now: there's a 'German cluster' at UYHB, a 'Scandinavian cluster' at TYFGH, a 'French / southern European' cluster at SDCV, and ç ñ € are at CNE which feels logical.

By the way, here is yet another of my proposals (sorry about the proposal spam), it's called "_wb_ international" in the big comparison table:

http://www.keyboard-layout-editor.com/#/layouts/01192fa1799361f7066da5897b76fb89

At a glance: Quite close to what I use, except pressing left diamond+shift might strain fingers like Fn+space did in default Pandora setup? Are triggers on the same side easy to press simultaneously?

If this gets chosen I'll be doing at least one swap: diamond+shift to between nubs like I got them now. I'm typing using that central "thumbing area" right now simply because the shoulder buttons are clicky and I got sleeping kids I don't want to wake next to me. Trust me - my hands are average sized or even smallish for an adult male and this works well, try it on you Pandora?

Edit: Do you have a justification for not "aping" the "general location" of some keys from regular keyboards? For example =+ one is at last row, not first (qwerty) one?

I sure hope that the shoulder buttons on the same side are easy to press simultaneously; if not, then certainly Shift and diamond would have to be on different sides.

Putting Meta (diamond) and Shift between the nubs means two out of Ctrl, Alt and Super would have to go elsewhere. I hope the Pyra shoulder buttons make less of a clicky noise when pressed; I agree that the Pandora shoulders can be a bit loud. The clicky feeling is good, the clicky sound is just annoying.

I tried to "ape" the "general location" of the punctuation keys better now. It was not so good in the previous version because I wanted to keep Ö at Meta+O, but I now realized that it's just as good to simply have a little 'German cluster' around Meta+U.

To be clear: in this proposal, all those language-specific symbols are actually labelled (I wouldn't be able to remember their location otherwise), but they are labelled in a darker shade and use a less bold font than the ASCII symbols. This is a compromise between ease-of-use (unlabelled symbols are bad) and visual clarity (lots of weird symbols cluttering up the keys is bad).

 

[TrashyMG]

The clicky feeling is good, the clicky sound is just annoying.

I barely notice a sound on mine... although I am typing away with an old IBM Model M right now, so something making a sound wouldn't really bug me. 

 

[Grench]

Here is a somewhat improved version of _wb_ international ("_wb_ intl 2") in the big table:

http://www.keyboard-layout-editor.com/#/layouts/7154da244376c7bc3db1fa65ca878431

I like the positioning tweaks. I suspect you do too. It is evolving in a positive direction.

I went down a parallel path, and this is the direction it took me.

This _wb_keyboard and one of my earlier layouts are actually very similar. We took similar paths to solving several of the compromise issues.

http://www.keyboard-layout-editor.com/#/layouts/fcd69e93d9f1fdd811c8d13cc212f3a6

One of the primary differences is in how the keyboard behaves for Alt+key actions without using the shoulders (desktop/dock/ingame use). Simplifying this question, "How hard is it to input Alt+F4 or Ctrl+F8 without using the shoulders? (shoulders assumed to be in-use during game play)"

I got around that question by putting in lower keyboard Alt and Ctrl keys and allowing for a 'locked' Fn level. Then I started looking at my replies in these forums. I use a -lot- more symbols than I do numbers when typing, so letters+symbols is a good combination. In Linux PC gaming, I tend to use numbers and F1-F12 for a lot of the in-game controls. I use a Razer Naga mouse which maps nicely to these under Linux. So...

Letters + Symbols = good for web, forum, typing. Mild compromise for coding, but for that numbers is a direct trade off with symbols.

Numbers + F1-F12 keys = good for gaming.

This led me to the idea that pairing numbers and F1-F12 keys so that they can both be 'active' at the same time is a GOOD thing in general and a GREAT thing for a gaming device. This dictates that they cannot share the same keys in two different Fn levels.

Web, forum and typing use hit the symbol keys much harder than the numbers. Coding is a mix needing both. On the Pyra's compressed keyboard, we get one or the other on the unFn layer. Having symbols forward is no better or worse for coding than having numbers forward.

That was when I came up with this idea:

http://www.keyboard-layout-editor.com/#/layouts/9156e2971235de513c368a4f8aa49de0

That is how I got to this one. It is a logical thought out progression to get there.

Letters, Symbols, Fn keys, numbers. Two need to be on the UnFn layer, two need to be on the Fn layer.

Pairing them up, Letters MUST be on the UnFn layer. Letters require at least some symbols in their functions. It makes sense to pair them.

F1-F12 keys and numbers pair up VERY nicely for use in gaming, so long as they don't share the same keys on UnFn and Fn levels.

By pairing letters+symbols and F1-F12+numbers, the keyboard gets it's greatest flexibility. In games, you can have weapon/spell/other/macros/other selection on the F1-F12 and/or numeric keys. Tap both Fn keys at once and then be able to type out an in-game response if needed, then tap both Fn keys again to be back to your action mapping. For games, this is a win-win.

Numbers get used in a lot of things, but generally they're few and far between in everything but coding. You might type in an address, which will require some numeric input or a phone number. Being able to FnLock the numbers to the active layout helps when entering these long strings.

It makes a lot of logical sense. But, can people get past the knee-jerk reaction of, "Oh noo... I can't reach the numbers!!!"? That requires humans to follow logic, which is a rare event.

 

[comradekingu]

Non english people use a lot of non A-Z letters when typing, wouldnt that make letters+more letters a good combination? I dont see what there is to lose from that, if you get the very symbols you are talking about.

 

[Grench]

Non english people use a lot of non A-Z letters when typing, wouldnt that make letters+more letters a good combination? I dont see what there is to lose from that, if you get the very symbols you are talking about.

The keyboard's primary language is English. I make no apologies for that fact. I do, however, include the needed diacritics and symbols needed for the primary languages of English, German, French and Spanish with compose capabilities to make symbols (letters) for additional languages.

With the limited key space on the Pyra, you're not going to get a layout that you can directly map to Norwegian without severely compromising it's usage for English, German, French and Spanish.

Frankly, it's probably time for you to look at the other layouts and figure out which one of them really does work best for you. I have done that, and several of them are tolerable, but in my humble opinion they leave out a few things that could make them great. Of the rest of the keyboards proposed, which ones could you tolerate? Do any of them stand out as being more tolerable than the rest?

 

[comradekingu]

If you had done the research to look at a Norwegian and German keyboard you would know that its exactly the same in terms of letters.

ü is å.  ö is ø and  ä is æ.  As dedicated keys, in exactly the same place.

French keyboard also needs those keys, because they use it to type ù among other things. Then there is çñ in spanish. And so on and so on.

Can you tell what you mean by "severly compromised". I do look at the other layouts, and give feedback. Here is my concerns with your latest offering.

I have unscrupulously stolen every single aspect of what I think works.

Edit: I think I downplayed Scandinavia a bit. Yes its quite small compared to others, but nontheless we buy a lot of gadgets because we can afford it. Atleast thats what I see and think.

It is a very lucrative market to provide keyboard-variants for. Mechanical keyboards, laptops, etc.

Even the jolla-keyboard and librem-laptop has it, and those are the closest you will find in spirit and size.

Norway alone could buy all of the pyras in the first batch, and it would not even be one per 1000 people.

Notice how many of the people in the community are Scandinavians, and add to that the fact there will most probably be more if you give them a keyboard they can use.