It's the keyboard layout.

[Grench]

Nope. Numbers need to be unshifted. Can't type line numbers as a stream-of-consciousness type thing when coding if you have to keep banging the function key before you type each line of code.


Honestly, I can't see why we don't just use the same layout as the original Pandora. We all know that one by now.


D.

Ahh - a coder then. You have a choice of two of three sets to have behind the Fn layer.


1. Numbers, which can be all in a neat and easily to find line.


2. F1-F12, which nobody has argued should be 'forward' or 'top' layer.


3. The symbol keys. `~ [{ ]} \| ,< .> /?


On the Pandora the F1-F12 and the majority of the symbol keys were on the Fn/Meta layer. The symbol key pairs were also broken - which caused a compatibility issue with certain types of software (Example DosBox) that count on shift+[ to result in {. Now we know - and can build a better layout to avoid that issue entirely.


In your coding, which do you use more? Numbers or symbols? All of those times you had to go into the Fn/Meta layer on the Pandora and sift through the randomly arranged symbols on the Fn/Meta/Blue layer of the keys to find the right symbol... The symbols don't have a strict order that makes them easy to find on the Fn/Meta layer. Numbers do.


Symbols are used more often than Numbers. Numbers are easier to find on the Fn/Meta layer than symbols are. By having symbols on dedicated keys, it opens them up as dead keys for easy diacritics, which keeps them from having to be blatantly mapped over the top of other keys. This leads to broader language support including the most common letters of the German alphabet being where they're supposed to be for the Germans - who are building this for the rest of us - and to do so without compromising English.


Modern coding relies more on symbols <>[]{};'"`~ than it does on numbers. If you're hand writing line numbers in coding though... Are you coding in Basic? Fortran?


If not, then the symbols being top side are actually more important than numbers.


Now, all that said, the numbers are very easy to get to. Note that Fn is duplicated on both the keyboard AND a shoulder button. It works just like a shift key. Hold it down with one digit and select the symbols with another. Writing a long line of numbers? That's easy too - hit both Fn keys at the same time then the numbers and F1-F12 are all 'top side' and can be typed without touching Fn. Need a symbol or letter in the middle of your numbers? Easy. When Fn-locked, press either Fn button to temporarily un-Fn the keyboard. This works just like using shift on a Caps-lock activated keyboard.


Speaking of which, shift+shift = shiftlock. Slightly different from capslock in that it shifts the entire keyboard and holds it there. This is activated by pressing shift+shift.


This design is insanely flexible and should be very efficient, but you would have to get past the knee jerk response over the numbers row being on the Fn layer. They weren't put there on a whim. Yes, it is a slight trade off, but the benefits that are gained are pretty darn cool if I say so myself.


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


Picture yourself actually using it. Consider the coding efficiency gains of having the symbols on top.


Then there is gaming.


FPS/MORPG? Lock the Fn layer top and have contiguous numbers AND F1-F12 'locked' to the active/top layer of the keyboard.


But I'm not German... what do I do with those other 3 keys?


You don't -have- to do -anything- with them. BUT - if you're so inclined, there is nothing that says you cannot map them to OS or application macros and functions and/or use them as another 3 game pad buttons. Wait - what? 3 more game pad buttons on the right?

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

  ⌦C     ⇞Y

      ⇤A    ⇥B

  ⌫Z     ⇟X

          Ü

         Ö Ä

Note - that makes 9 buttons easily available for the right game pad area, all aligned for easy use.

This can work, it has piles of bonuses and benefits.

 

[codifies]

... code with lots of magic numbers in it..... What a dream to maintain...

 

[Saber]

Nope. Numbers need to be unshifted. Can't type line numbers as a stream-of-consciousness type thing when coding if you have to keep banging the function key before you type each line of code.


Honestly, I can't see why we don't just use the same layout as the original Pandora. We all know that one by now.


D.

Ahh - a coder then. 

...


Picture yourself actually using it. Consider the coding efficiency gains of having the symbols on top.

I'm not a coder but I think the Pyra becomes a more universal device to many more people if the numbers are on the top layer rather than behind modifier(s). 

 

[ZXDunny]

BASIC, of course. I write a lot of that on the Pandora, so of course it's more important to me that the number keys are most easily accessible. I do agree that sometimes the Pandora symbols were not logically laid out, but once learned I don't even have to look at the keyboard anymore.

The best argument for a number row is the post above; that it will be more readily accessible to people that expect there to be a row of numbers. Are there any devices out there (aside from GBA, NDS et al) that don't have a row of numbers? Those that have a proper qwerty keyboard that is.

And not phones, before anyone pipes up

D.

 

[Saber]

BASIC, of course. I write a lot of that on the Pandora, so of course it's more important to me that the number keys are most easily accessible. I do agree that sometimes the Pandora symbols were not logically laid out, but once learned I don't even have to look at the keyboard anymore.


The best argument for a number row is the post above; that it will be more readily accessible to people that expect there to be a row of numbers. Are there any devices out there (aside from GBA, NDS et al) that don't have a row of numbers? Those that have a proper qwerty keyboard that is.


And not phones, before anyone pipes up


D.

Spoiler

 

[Grench]

Nope. Numbers need to be unshifted. Can't type line numbers as a stream-of-consciousness type thing when coding if you have to keep banging the function key before you type each line of code.


Honestly, I can't see why we don't just use the same layout as the original Pandora. We all know that one by now.


D.

Ahh - a coder then. 

...


Picture yourself actually using it. Consider the coding efficiency gains of having the symbols on top.

I'm not a coder but I think the Pyra becomes a more universal device to many more people if the numbers are on the top layer rather than behind modifier(s). 

Instead, you've taken all of the keyboard symbols and thrown them in a blender and populated them to the Fn/Meta layer, lost compatibility for software needing symbol pairs maintained and thrown in a 3rd shift key.  You sacrifice usability, gaming capability, language compatibility and DosBox compliance and broke up the F1-F12 row JUST so you can put the numbers on the top layer.

BASIC, of course. I write a lot of that on the Pandora, so of course it's more important to me that the number keys are most easily accessible. I do agree that sometimes the Pandora symbols were not logically laid out, but once learned I don't even have to look at the keyboard anymore.


The best argument for a number row is the post above; that it will be more readily accessible to people that expect there to be a row of numbers. Are there any devices out there (aside from GBA, NDS et al) that don't have a row of numbers? Those that have a proper qwerty keyboard that is.


And not phones, before anyone pipes up


D.

It has a number row.  It's on the same row and keys that others are using for numbers.  It simply requires using one of two Fn buttons to activate.  It isn't difficult and doesn't require huge thought.  Just press a shoulder button and type in your numbers then let go of the shoulder button.  Alternatively you can use the Fn button on the keyboard itself - options galore.

You're acting like the number row has been totally removed from the device or made so that they require a blood draw to use.

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



If you're used to using the Left shoulder to shift on the Pandora, then L1 = shift will feel natural to you.  L2 = Fn works just the same exact way.  Mash both to get the shift+Fn layer.  Numbers won't slow you down just because they're on the Fn layer.

Did you even consider all of the things that we can -gain- from doing this?  I listed a lot of benefits above.

And no, I'm not aware of any company making a keyboard exactly like this one.  Last i checked, nobody else is making anything like the Pyra either.

 

[WizardStan]

BASIC, of course

SpecBAS and therefore by extension PandaBAS still requires line numbers and doesn't have autonumbering? That's seriously antiquated.But on a different note, your use case is in a very very small subset of a minority of users: if FN layer numbers turns out beneficial for the average user then I'm sorry but you'll just have to suck it up. As a C++ developer I'd much rather have all the brackets and other punctuation on the main layer even if it means relegating the number row to the FN layer. So my programming preference counteracts your programming preference and we're forced to ask not-us for input

Unless you have a layout that makes both number BASIC and C++ easy?

 

[Saber]

Nope. Numbers need to be unshifted. Can't type line numbers as a stream-of-consciousness type thing when coding if you have to keep banging the function key before you type each line of code.


Honestly, I can't see why we don't just use the same layout as the original Pandora. We all know that one by now.


D.

Ahh - a coder then. 

...


Picture yourself actually using it. Consider the coding efficiency gains of having the symbols on top.

I'm not a coder but I think the Pyra becomes a more universal device to many more people if the numbers are on the top layer rather than behind modifier(s). 

Instead, you've taken all of the keyboard symbols and thrown them in a blender and populated them to the Fn/Meta layer, lost compatibility for software needing symbol pairs maintained and thrown in a 3rd shift key.  You sacrifice usability, gaming capability, language compatibility and DosBox compliance and broke up the F1-F12 row JUST so you can put the numbers on the top layer.

My layout does not sacrifice usability or so-called DOSBox compatibility by having symbol pairs on separate keys rather than different modifier levels like yours has them. I've shown in earlier iterations, my April 23rd v1.1 layout, how these pairs could still be present but veiled. For example, on [ and ] by way of Shift + Fn there lies { and } and the same for the other U.S. International pairings: again under Shift + Fn with \ is | and - is _ and = is + and so on yet all of these keys are accounted under the Fn level too, which is a good thing. 

As for F1-F12 all in a row, I don't care much for that as I like how the number row, in my layout at least, correlates to the first ten of them. Also, the other two F11 and F12 are, as many of the symbols, in or near their recognized Pandora placements.     

 

[Grench]

My layout does not sacrifice usability or so-called DOSBox compatibility by having symbol pairs on separate keys rather than different modifier levels like yours has them. I've shown in earlier iterations, my April 23rd v1.1 layout, how these pairs could still be present but veiled. For example, on [ and ] by way of Shift + Fn there lies { and } and the same for the other U.S. International pairings: again under Shift + Fn with \ is | and - is _ and = is + and so on yet all of these keys are accounted under the Fn level too, which is a good thing. 

Somehow you keep misunderstanding what this really is.

Regardless of the layout, shift+[ will result in { under DosBox, even if [ is on the Fn layer. Just like it does on the Pandora. Call this a 'hidden positive'.

However, you also have a Fn layer { key labeled on your layout, but pressing it in DosBox will yield either nothing or an unpredictable result. Call this a 'labeled negative'.

In order for your end user to use DosBox or similar software that runs off of the hardware keyboard level, they must memorize all of the US Standard key pairs to know which key's pair they need to find AND whether or not they should ignore the actual label for the key they're looking for.

It is a confused mess from two directions at once.

A much better solution is to label and arrange the keys so that what they are labeled as and what they do are the same thing regardless of the software application or game being used. We CAN do that. It is as simple as maintaining the key pairs as they are on a normal US Standard keyboard. You are choosing not to do that and as a result are deliberately incorporating incompatibility into your layout.

As for F1-F12 all in a row, I don't care much for that as I like how the number row, in my layout at least, correlates to the first ten of them. Also, the other two F11 and F12 are, as many of the symbols, in or near their recognized Pandora placements.

So - you're doing that way for a sense of aesthetics because 1-0 and F1-F12 both have numbers in their labels and because you want it to be just as incompatible as the Pandora? The Pandora layout wasn't very good. It broke DosBox and made non-English languages very difficult. Finding symbols on the Fn layer was annoying - though eventually we got used to it - or stopped playing it. We can do MUCH better. This is a opportunity to fix this.
HalfLife has just been made playable on the Pandora. Linux PC Gaming on the Pyra is going to be a real thing - quite possibly a big thing. PC FPS and MORPG games often use the numbers and/or F1-F12 to handle skill/weapon/spell selection and communications. Often it's a -good- thing to be able to access them both nearly simultaneously. We can't do that efficiently if they're mapped to the same physical keys and/or being on different layers. Having the numbers and the F1-F12 keys both contiguous AND on the same Fn layer gives the Pyra a big advantage when playing these types of games. In my layout, I consider the numbers and F1-F12 to be an extension of the game pads. They're strung up there where they can be easily accessed from the nubs and game pads. Put the unit in Fn-lock mode and you have 23 keys, the whole top two layers, to use as in-game functions.

This is a leap forward in capability, compatibility, usability AND brings along enhanced non-English use with no-apologies needed German support without any negative impacts to English use.

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

 

[Saber]

This is a leap forward in capability, compatibility, usability AND brings along enhanced non-English use with no-apologies needed German support without any negative impacts to English use.

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

It's not a leap anywhere when you've introduced these "features" by removing set standards(like the number row as primary and those symbols normally found as their Shifted values like !@#$%^&*() which now require TWO modifiers to access). Also, where are the hardware toggles for WiFi/4G/BT and such in your newest creation? 

 

[Grench]

This is a leap forward in capability, compatibility, usability AND brings along enhanced non-English use with no-apologies needed German support without any negative impacts to English use.

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

It's not a leap anywhere when you've introduced these "features" by removing set standards(like the number row as primary and those symbols normally found as their Shifted values like !@#$%^&*() which now require TWO modifiers to access). Also, where are the hardware toggles for WiFi/4G/BT and such in your newest creation?

Number row hasn't gone away it is on an easily accessible Fn layer activated either on the left shoulder or keyboard. It is VERY easy to remember where it is. It is VERY easy to use. The numbers are in order, so there is no 'hunting for stuff on the Fn layer'. With the keyboard in Fn-Lock mode, that entire number row AND the F1-F12 row under it instantly become additional game buttons on the top layer. All of them.

This instantly yields a 33+2(nubs) button game controller WITHOUT mapping any letters to the game.

Symbols on the number row are on the Shift+Fn layer, but you're deliberately overstating the "inconvenience" of this. The shift and Fn keys on the shoulders and on the main keyboard area are intentionally next to each other. This enables the user to chord them - press both simultaneously. It is ONE press action, just covering two buttons. Just like mashing two buttons next to each other on a game controller. The symbols on the number keys are no more difficult to access than they are on a standard keyboard.

To create the $ symbol:

Standard keyboard: Hold shift (one action), press 4/$.

The above keyboard: Hold shift+Fn (one action), press R/4/$

Very simple. Very easy. It is no slower nor more difficult to create !@#$%^&*() on this keyboard than it is with one having 'numbers on top'.

Hardware toggles for WiFi/4G/BT/HDMI/USBOTG/USB/SoftVolume&mixer/LidBackLED/Vibration/Microphone/etc.. are all handled through the ≡ key (left side of top row). This is a shortcut key to pull up the hardware control menu in the OS. Preferably on one of the reserved overlay layers.

Hardware toggles for screenbacklight and keyboardbacklight are in one button (top right).

No modifiers: Screen brightness up.

Shift: Screen brightness down.

Fn: Keyboard brightness up.

Fn+Shift: Keyboard brightness down.

PrtSc and Pause may look a bit odd up there by themselves, but they do not live well on a Fn layer. They're most common use is with modifiers - but not shift or Fn. Alt+PrtSc (capture window to buffer) needs to be accessible. Ctrl+Pause/Break needs to be accessible. Where I put them ensures this, but also puts them where they're easily mapped and usable in gaming.

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

We can do this.

 

[ZXDunny]

If you're used to using the Left shoulder to shift on the Pandora, then L1 = shift will feel natural to you.  L2 = Fn works just the same exact way.  Mash both to get the shift+Fn layer.  Numbers won't slow you down just because they're on the Fn layer.

 No, I don't use the shoulder buttons - that's daft, as I use the Pandora on a desk. Looks like I might have to use two hands to type numbers though, especially if the keys are as hard to press as the Pandora is. I know ED said they're softer, but I'll believe that when I see it.

BASIC, of course

SpecBAS and therefore by extension PandaBAS still requires line numbers and doesn't have autonumbering? That's seriously antiquated.

To all three of your statements, "Yes", "No" and "Yes, that's the point".



D.

 

[Grench]

If you're used to using the Left shoulder to shift on the Pandora, then L1 = shift will feel natural to you.  L2 = Fn works just the same exact way.  Mash both to get the shift+Fn layer.  Numbers won't slow you down just because they're on the Fn layer.

 
No, I don't use the shoulder buttons - that's daft, as I use the Pandora on a desk. Looks like I might have to use two hands to type numbers though, especially if the keys are as hard to press as the Pandora is. I know ED said they're softer, but I'll believe that when I see it.

OK - it can do desktop use.  When working on a Pandora on a desktop I use 2 digits (thumb and index finger) per hand.  To do numbers on this keyboard while on the desktop:

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

I would push Fn with my left thumb and touch numbers 1-4 with my left index finger and 5-0 with my right index finger.  Easy.

Fn+Shift are chordable either on the left shoulder or the lower left keyboard - your left thumb can cover/mash them both or selectively either one.  It will quickly become natural.

 

[Caine]

I do really like that symbols are properly paired in the layout by Grench.

The bottom row rubs me the wrong way a bit. The bottom middle keys are fairly hard to reach and contain VERY common keys on the shell and while programming (i.e. '|', '\', ';' and ':' ). I would really prefer to see those swapped with the (for me) unused keys next to the P and the L. I.e. :; and '" next to L and move \| next to P.

I am also a bit unsure about having to Fn+Shift some keys (i.e. with the double modifier), though Grench did pair them up such that you can strike them with a single finger. When typing on the table a becomes a tad awkward though.

 

[Saber]

This is a leap forward in capability, compatibility, usability AND brings along enhanced non-English use with no-apologies needed German support without any negative impacts to English use.

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

It's not a leap anywhere when you've introduced these "features" by removing set standards(like the number row as primary and those symbols normally found as their Shifted values like !@#$%^&*() which now require TWO modifiers to access). Also, where are the hardware toggles for WiFi/4G/BT and such in your newest creation?

Symbols on the number row are on the Shift+Fn layer, but you're deliberately overstating the "inconvenience" of this. The shift and Fn keys on the shoulders and on the main keyboard area are intentionally next to each other. This enables the user to chord them - press both simultaneously. It is ONE press action, just covering two buttons. Just like mashing two buttons next to each other on a game controller. The symbols on the number keys are no more difficult to access than they are on a standard keyboard.

I have this same(gimmick?) in my layouts too where the person could chord Fn and Shift by covering both of them with a thumb or index finger to get a new level of values, but I don’t much care for the average Pyra user to be pushed to have to do this every time, particularly for standard punctuation. In my layouts in my sig below, for symbol sets !@#$%^&*() and - _ = + { [ ] } \ | : : ‘ “ < > / ? you’d press either a single Shift key or a sole Fn(Meta) key. Those are also ONE press actions and they are delivered without the cost of demoting the entire number row behind Fn(Meta).

I’d also like to state that as much as some really dislike it and disagree with having two keyboard Shifts, and I do understand their side of it, that there are your fellow members who don’t concede the shoulder trigger Shift key in text entry tasks at all, and that if we do have two keyboard Shifts as in my layouts with Left Shift on the right side and Right Shift on the left side(and also reflected on L1), this arguably disposable Left Shift key could become at the user’s discretion by remap any key or keys they’d like it to be: Å, Ç, Ñ, /, \, |,  , Tab, SysRq, Pause, Menu, Super, all three of å, æ, ø, the Compose key, or even a dedicated Escape key should they want it there.    

 

[Saber]

Added an alternative form of the v5.0 layout(my main proposal) called v5.0b to the spoiler and my sig below. 

Spoiler

 

[Eight Bit]

It's starting to look a little like my keyboard now Saber, though mine is a little less german centric.

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

 

[codifies]

It's starting to look a little like my keyboard now Saber, though mine is a little less german centric.

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

I think left shift would be better off where the comma is... this would make it easier to mash with thumb/finger sides while rolling the hand to jab at some other near by key...

 

[Eight Bit]

It's starting to look a little like my keyboard now Saber, though mine is a little less german centric.

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

I think left shift would be better off where the comma is... this would make it easier to mash with thumb/finger sides while rolling the hand to jab at some other near by key...

I think you are right... It would be better.

For consistency the meta should go one key up and the right shift one key down then too I guess.

It would break the Pandora compatibility scheme though.

Here's a version with the alterations you suggested. I also moved the diacritics around a bit.

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

 

[codifies]

I'm honestly not being picky! But looking again, the escape looks too surrounded would it cause a storm of controversy if it was on meta-pyra ?


What you use the spare meta key for then I'm not sure but a spare function on such a tiny keyboard is never a bad thing...!


Its looking like a sane layout though...