It's the keyboard layout.


Oh for a layout that had the control keyboard actually on the keyboard! Rather useful when doing maintenance via SSH on various systems...
If you mean a Control key, and you don't want to hold Select(which is Left Control) or shoulder R1(which is Right Control), why not map one of the keyboard Left Shifts to it, if you are backed into a corner that is? 
 
Last edited by a moderator:
I never found either comfortable...
Other than my remap suggestion above, how about ordering the center column between the nubs to Start, then Menu, then Select at the bottom, at least on your Pyra?
 
Yeah I can see me buying tipex when I get a pyra....
Save your rupees. Askarus moved his Z and Y keys: 

cimg5899w.jpg
 
Last edited by a moderator:
Oh for a layout that had the control keyboard actually on the keyboard! Rather useful when doing maintenance via SSH on various systems...
If you mean a Control key, and you don't want to hold Select(which is Left Control) or shoulder R1(which is Right Control), why not map one of the keyboard Left Shifts to it, if you are backed into a corner that is? 
But there IS one that does this the way the user wants to use his keyboard.  Actual Alt and Control (Ctrl) keys on the keyboard in a usable position where the end user would expect to find them.  No Vulcan death grip to reach the center keys in combination with others required - even without using the shoulder buttons.

There is a proposal that meets this user's needs.

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

Key pairs retained.  Keys present where the user expects them to be - or as near to that as possible.  Fully functional F1-F12 keys.  Language support clearly stated.  AltGr (Right Alt) retains it's capability if a non-US keyboard map is assigned at the OS level.
 
I agree while that layout definitely has potential, it is a bit cluttered at the moment! - but certainly not beyond improvement

Is it fair to say btw that certain diacritics can be assumed and don't actually need a label - for example A and Ä

Is this a reasonable enough assertion that a majority can get behind ? or is this unfair to none English speakers?

Could a consensus be reached as to what "English" characters should provide which diacritics - could a table be compiled to aid layout design?

This idea is either wholly unfair or could be a useful solution to the problem of overcrowded cluttered looking layouts - I really don't write in enough languages to know!
 
Nice, bit crowded on the labels but a decent lay-out imo. I do ask myself why the ABXY buttons are the other way around compared to the pandora. :)
You're right.  Fixed.  Thank you for the feedback!

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

I agree while that layout definitely has potential, it is a bit cluttered at the moment! - but certainly not beyond improvement

Is it fair to say btw that certain diacritics can be assumed and don't actually need a label - for example A and Ä

Is this a reasonable enough assertion that a majority can get behind ? or is this unfair to none English speakers?

Could a consensus be reached as to what "English" characters should provide which diacritics - could a table be compiled to aid layout design?

This idea is either wholly unfair or could be a useful solution to the problem of overcrowded cluttered looking layouts - I really don't write in enough languages to know!
In the battle between 'Cluttered' and 'Great Functionality' I tend to err toward the functionality side.

Since we're key-limited and want a contiguous F1-F12 key set, there isn't room to add 'assumed' diacritics to the UIO keys.  The German letters presented are a nod to the German origins of the Pyra.  However, French and other languages use several different diacritics, so that is why there is a dedicated 'Diacritic Key' on this layout.  As a fall-back, there is a compose key, which should allow any language support, but is nowhere near as easy to use.  So, 3 levels of support for non-English use.

The idea is to have English be the easiest, then German, French, Spanish, and whatever else I can get in.

The Pyra is intended as an international device.  What may add 'clutter' to the 'standard US' layout, is intended to enable non-English speakers needed functionality.

Can you put up with 'clutter' on keys you won't use for the sake of making the device usable by German, French, Spanish and other native speakers?  (Please say, 'yes'.)
 
Last edited by a moderator:
  • Like
Reactions: szr
Do we defiantly want contiguous  f1-f12 quite a large number of "full" keyboards have "only" f1-f10 ...
 
Do we defiantly want contiguous  f1-f12 quite a large number of "full" keyboards have "only" f1-f10 ...
The only one with F1-F10 that I can think of off hand was the original IBM PC keyboard.  I haven't seen a mass produced keyboard in the last 20 years with less than 12.

What is your example?
 
If you err towards functionality, then why implement the pandora layout? Almost nothing functions that way.

It breaks to the greatest extent what existing conventions there are, in a confusing manner.

Adding Z and C in places they arent in on other controllers, just adds insult to injury.

Ways of dealing with the F-row issue,

  • F1-F10 only is just not a full F-row. Expecting people to not notice F11 and F12 missing wont work
  • F1-10 with F11 and F12 stepped, looks broken, and draws attention to how few buttons there are 1000x more, since its such a ugly compromise.
  • F-1-F12 on QWERTY looks out of place, and was only halfway popular in the vote.
This is a best a visual problem.

Solution: just dont print it, and do the instructions in conky. Functionality is still there for the people that have use for them to learn, and the novices will have less visual clutter to deal with.

Then its down to the individual to change it to their liking, or even freely use meta+area for other things.

F-keys are headed the way of the G-keys. Not printing them and still implementing, solves the issue, and keeps things looking fresh and updated.
 
Last edited by a moderator:
http://i.imgur.com/kU3HM.jpg :)

I've so rarely used f11 f12 (ever?) that I never saw anything unusual than the fact they were missing on my keyboard... so I really don't see the issue with them not being contiguous... whats the big deal about f11 and f10 not being next to each other?
 
http://i.imgur.com/kU3HM.jpg :)

I've so rarely used f11 f12 (ever?) that I never saw anything unusual than the fact they were missing on my keyboard... so I really don't see the issue with them not being contiguous... whats the big deal about f11 and f10 not being next to each other?

Interesting, but niche, examples.  Most users are going to expect them to be present and functioning.

I'm going to put this one in the, 'better to have them and not need them than to need them and not have them,' class.
 
Nice, bit crowded on the labels but a decent lay-out imo. I do ask myself why the ABXY buttons are the other way around compared to the pandora. :)
You're right.  Fixed.  Thank you for the feedback!

http://www.keyboard-layout-editor.com/#/layouts/fcd69e93d9f1fdd811c8d13cc212f3a6
Interesting layout, though I have one question. You have Break as FN + Pause (right below Start and Select), though looking at my own full-size keyboard, Break is usually simply Shift + Pause, so would it really need to be an FN key? If the normal Shift + Pause were to be used for Break, then FN + Pause could be used for something else.

Also, would it not make sense to use "Start" for the Pause key, given how Start in many console (many of which will be emulated) use "start" to pause/unpause the game? Seems like it would be rather fitting imho.

Either way, I like how the Pyra is turning out, can't help but be exited. :)
 
Last edited by a moderator:
Back
Top