And now for something completely different (Keyboard Option)


Going a step beyond...  A Pyra with the screen removed in your shirt breast pocket, heads up display in your sunglasses or a helmet display.  Secret Cyborg fantasies anyone?
 Jumping back to the forearm mounting, but sans top half, with a HUD might be a good wearable computer.  Another cool idea, even if a bit outdated due to touchscreen portable devices and such.
OK - to do this right we'd really want/need a custom case. Consider this:

It's going to be built to strap tho the left forearm (for lefties consider a mirror mold). The main unit could easily be made thinner by splitting the battery and SoC/keyboard levels apart.

The battery compartment is up-arm from the SoC/Keyboard. The SoC/Keyboard rides closer to the wrist. The whole thing then becomes 1/2 as thick but twice as wide - which is fine.

So - it becomes a unit 11" long and 3" wide and 1/2" thick connected to stretchy cuffs to go around the forearm.

Then it's just a single cable running up the left arm through the collar to a pair of headphones and a Google Glass type display - preferably one inside the glasses without the annoying camera and Google computer in it.

Wear a long sleeve shirt with over-sized cuffs and 80% of people would never even know you're wired.
 
/**** Multiple Mice oh noes! ****/

Regarding _wb_'s concern about having more than one set of mouse 1 & 2 buttons, that is a non-issue. Anyone who has used 2 mice or an IBM/Lenovo Ultranav keyboard and mouse (3 mice at once), it's simply a non-issue.

I'm glad putting tab on Fn-space and shift tab on shift+Fn+space is an acceptable alternative. I disagree that tab requires a dedicated key in this layout as nothing is more than one chord-stroke away.

/**** Shift lock OK - but Ctrl Lock and Alt Lock is weird! ****/

Regarding the comment around 'Why have Ctrl-lock and Alt-lock?'. This is a convenience for the upcoming needs of the players of PC games that should be usable on the Pyra. There are -many- games from the last 10 years that have used the Fn keys &/or the numeric keys for stored in-game actions. Examples of this include: The entire Half-Life franchise, World of Warcraft, Neverwinter Nights, etc. In these games there is a huge advantage to being able to instantly flip to a new set of mappings for F1-F12 and/or 1-0 by using Ctrl or Alt + key. On a standard keyboard, you have to hold the Ctrl or Alt while selecting the alternate mapping, which is a bit of an annoyance. On this keyboard the player will have the option to lock the F1-F12 and 1-0 keys into and out of Ctrl and Alt modified states with ease.

/**** International users feedback needed ****/

Does having Comp on Fn+Shift+Enter satisfy the international keyboard users needs?

/**** Current version of this layout so you don't need to scroll back ****/

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

As always, constructive feedback is welcome. Please subject it to a 'mental beta test'. Consider what you use a keyboard and mouse for on a daily basis. What applications you're using, what games you're playing, etc. Then consider if/how those would work on this keyboard layout.

Advertising or promoting your own keyboard should be done in your own thread please? Lets reserve each maker's thread for the purpose of making each layout as good as possible. You're welcome to help me make mine as good as it can be. I'll try to return the favor with constructive feedback to yours. We can then have a 'proper shootout' if/when Ed says he's ready for it. He's well within his rights to just ignore the whole discussion and do as he pleases.
 
Personally I think all keyboard discussion should be in the one master thread to avoid cluttering up the forum for everyone, but since we're here, I agree - your thread for your keyboard.


I suppose I don't need a dedicated tab if the modifier to activate it isn't on the same side of the keyboard. I can't say exactly what my trouble is with the Pandora's tab, as I can't replicate it in controlled conditions, but I can only assume that since I need to use my right thumb for FN and space, and I haven't mastered the thumb splodge technique, I use a bounce technique - bouncing off FN and onto space, and I just don't bounce hard enough always. If I can use my other thumb, no need for a complicated bounce.


One little concern I have is hand-editing XML on this keyboard. It's something I've needed to do on Pandora before, and it was a pain, with different adjacent characters being on different modifiers.


Let's see, on yours an empty 'foo' tag is: Shift+Fn+(, foo, /, Fn+(. I guess that's okay actually. That's a pass.


I think I'd prefer to have brackets on adjacent keys using the same modifier, rather than on the same key with varying modifiers though - one less variable to consider (so the above example might just become Fn+(, foo, /, Fn+) ). That'd be easy to change for square and curly ones on your layout, but more taxing for parentheses and arrow brackets/gt/lt since 0 can't really be moved. I could survive with having pipe (|) on a modifier if that helps free up a slot.


And perhaps back-tick and forward-tick/apostrophe should be switched so that back-tick is on Shift+Fn and apostrophe on just Fn, as apostrophe is likely to be more used by almost all users IMO.
 
/**** Multiple Mice oh noes! ****/


Regarding _wb_'s concern about having more than one set of mouse 1 & 2 buttons, that is a non-issue. Anyone who has used 2 mice or an IBM/Lenovo Ultranav keyboard and mouse (3 mice at once), it's simply a non-issue.
OK, but how then does a game distinguish shoulder button presses from nub clicks, in case it wants to use those for different game actions? With modifiers you can distinguish e.g. Left Ctrl (SELECT) from Right Ctrl (R1), but how do you distinguish Left Mouse click from Duplicate Left Mouse click?

I'm glad putting tab on Fn-space and shift tab on shift+Fn+space is an acceptable alternative. I disagree that tab requires a dedicated key in this layout as nothing is more than one chord-stroke away.
It's only acceptable in the sense that it works, whereas a layout that does not allow you to enter Shift-Tab simply does not work. It's still not a very good location for Tab.


Tab on the Pandora is only one chord-stroke away. Still, many people say that's not good enough. Tab is quite important for Tab completion and Alt-Tabbing. Probably about as important as the arrow keys and space. Would you consider a dpad that only does arrow keys when you hold down Fn acceptable?

/**** International users feedback needed ****/


Does having Comp on Fn+Shift+Enter satisfy the international keyboard users needs?

Just a Compose key alone is enough for me (since my main language is Dutch, which uses many diacritics but only sporadically), but for most other languages, it is certainly not enough. You need to press at least 3 keys per letter using the Compose method (not counting the modifiers), which is not acceptable if you need to do that many times per sentence.


A heavy user of Compose will remap Compose to a single key anyway, e.g. right Alt or right Ctrl or something. Fn+Shift+Enter as a default is OK I guess.


For international needs, it's best if P+1 and L+2 are available to put other symbols on. One way to do that is by putting not so crucial symbols on those keys, and by don't having any Fn labels on those keys. Then if you want to map P+1, L+2 to e.g. Ü Ö Ä, you can put the original keys at Fn+Ü Ö Ä.


For international needs, some mechanism for dead diacritics is also nice (two key presses, not counting modifiers, instead of three with Compose).


Finally, in some languages (e.g. French), the number row is used for letters, so if a layout does not have a number row, some solution has to be thought of for such languages.
 
Last edited by a moderator:
/**** Multiple Mice oh noes! ****/

Regarding _wb_'s concern about having more than one set of mouse 1 & 2 buttons, that is a non-issue. Anyone who has used 2 mice or an IBM/Lenovo Ultranav keyboard and mouse (3 mice at once), it's simply a non-issue.
OK, but how then does a game distinguish shoulder button presses from nub clicks, in case it wants to use those for different game actions? With modifiers you can distinguish e.g. Left Ctrl (SELECT) from Right Ctrl (R1), but how do you distinguish Left Mouse click from Duplicate Left Mouse click?
Simple - it doesn't. They're the same button/switch as far as it is concerned. Wire two switches A and B into one circuit in parallel. Put a light at the end. Push button A, light comes on. Push button B, light comes on. Push both, light comes on. Push button A, light comes on, hold it while you push button B, light stays on, release button A, light is still on as B is still pressed. No issue and no need to distinguish between a left mouse click on the red nub pointer in the middle of the keyboard or the one on the trackpad or the one on the mouse. They're all 'Mouse 1' and that switch is either on (clicked) or off (unclicked).
I'm glad putting tab on Fn-space and shift tab on shift+Fn+space is an acceptable alternative. I disagree that tab requires a dedicated key in this layout as nothing is more than one chord-stroke away.
It's only acceptable in the sense that it works, whereas a layout that does not allow you to enter Shift-Tab simply does not work. It's still not a very good location for Tab.
Tab on the Pandora is only one chord-stroke away. Still, many people say that's not good enough. Tab is quite important for Tab completion and Alt-Tabbing. Probably about as important as the arrow keys and space. Would you consider a dpad that only does arrow keys when you hold down Fn acceptable?
Tab on the Pandora is not a chorded stroke as there isn't a 2nd digit to do the modifier. On the Pandora it is important which gets engaged first, Fn or space - while still trying to mash it with a single thumb.
That is a non-issue on my keyboard as it's a different thumb doing the modifier than the one hitting the space bar. The space bar is unique on the keyboard in that either thumb can reach it while the other one goes back to the modifier pad set if needed.

Where the Fn+space=tab on the Pandora is awkward due to the required buttons being next to each other, my keyboard gives two comfortable ways to get the result quickly.

/**** International users feedback needed ****/

Does having Comp on Fn+Shift+Enter satisfy the international keyboard users needs?
 Just a Compose key alone is enough for me (since my main language is Dutch, which uses many diacritics but only sporadically), but for most other languages, it is certainly not enough. You need to press at least 3 keys per letter using the Compose method (not counting the modifiers), which is not acceptable if you need to do that many times per sentence.

A heavy user of Compose will remap Compose to a single key anyway, e.g. right Alt or right Ctrl or something. Fn+Shift+Enter as a default is OK I guess.
I'll take that as a step in the right direction for adding international support then. Thank you.
For international needs, it's best if P+1 and L+2 are available to put other symbols on. One way to do that is by putting not so crucial symbols on those keys, and by don't having any Fn labels on those keys. Then if you want to map P+1, L+2 to e.g. Ü Ö Ä, you can put the original keys at Fn+Ü Ö Ä.
This part is confusing to me... Does it have to be P+1 and L+1 or is there a reason why my Fn+G and Fn+H (and Fn+shift+G and Fn+shift+H) that I left open for custom mapping could not work? Or am I misunderstanding the need?

For international needs, some mechanism for dead diacritics is also nice (two key presses, not counting modifiers, instead of three with Compose).
Do you have a link describing how this works? I have no point of reference here.
Finally, in some languages (e.g. French), the number row is used for letters, so if a layout does not have a number row, some solution has to be thought of for such languages.
My inclination is to let them use the 4 custom keys + compose. If they need more than that, they can start getting into alt+letter mappings at the OS level. Those are all available - the entire keyboard - since there is an alt on both sides. They can even lock-mode it into Alt mappings if they want to and custom code the entire alphabet set on the keyboard. I would recommend staying out of the ctrl-letters set as those have special meanings in many cases.
So there are a lot more potential mappings than we're really giving it credit for. The big battle is more around what to print on the individual key labels. With Alt-letter mappings added in - plenty of room to pile on most non Asian languages. Those get far more complex than I'm willing to try to map onto a handheld without a team of native speaking assistants.
 
Personally I think all keyboard discussion should be in the one master thread to avoid cluttering up the forum for everyone, but since we're here, I agree - your thread for your keyboard.

I suppose I don't need a dedicated tab if the modifier to activate it isn't on the same side of the keyboard. I can't say exactly what my trouble is with the Pandora's tab, as I can't replicate it in controlled conditions, but I can only assume that since I need to use my right thumb for FN and space, and I haven't mastered the thumb splodge technique, I use a bounce technique - bouncing off FN and onto space, and I just don't bounce hard enough always. If I can use my other thumb, no need for a complicated bounce.

One little concern I have is hand-editing XML on this keyboard. It's something I've needed to do on Pandora before, and it was a pain, with different adjacent characters being on different modifiers.

Let's see, on yours an empty 'foo' tag is: Shift+Fn+(, foo, /, Fn+(. I guess that's okay actually. That's a pass.

I think I'd prefer to have brackets on adjacent keys using the same modifier, rather than on the same key with varying modifiers though - one less variable to consider (so the above example might just become Fn+(, foo, /, Fn+) ). That'd be easy to change for square and curly ones on your layout, but more taxing for parentheses and arrow brackets/gt/lt since 0 can't really be moved. I could survive with having pipe (|) on a modifier if that helps free up a slot.

And perhaps back-tick and forward-tick/apostrophe should be switched so that back-tick is on Shift+Fn and apostrophe on just Fn, as apostrophe is likely to be more used by almost all users IMO.
OK - so I may need to go back to paired brackets on neighboring keys with similar Fn/Shift levels. For positioning, it would be handy to prioritize or rank them in order of usefulness.

()

{}

[]

<>

/\* <= Yes, 3 as / is involved in two paired sets.

+-

Which sets of brackets do you use the most? 2nd most? 3rd?

Thanks!
 
I'd say that ordering is about right. Brackets/parens first, as they're used in natural language and function calls in most programming languages I know, curly braces as level indicators in C/Java etc (and map referencing in Perl/Python), while square brackets are pretty much only used for array indexing when programming (and commonly used as secondary brackets in filenames etc.). I'd be tempted to put angle brackets above them as they're the brackets in SGML/XML and greater than and less than everywhere else.


I don't see forward and backward slash as a pair really - they're never used together like that. When forward slash is used as a bracket, such as the original wiki italics identifier, or in regular expressions, it's just a pair of forward slashes, and back slash is used to escape characters in unix, and as the directory separator in DOS. I'm also not sure how / and * are a pair in anything.


Edit: I suppose you'd use \/ to escape a slash in a filename on the terminal, but escaping stuff usually involves a modifier for the backslash then none for the escaped character so they're still not paired IMO.
 
Last edited by a moderator:
I'd say that ordering is about right. Brackets/parens first, as they're used in natural language and function calls in most programming languages I know, curly braces as level indicators in C/Java etc (and map referencing in Perl/Python), while square brackets are pretty much only used for array indexing when programming (and commonly used as secondary brackets in filenames etc.). I'd be tempted to put angle brackets above them as they're the brackets in SGML/XML and greater than and less than everywhere else.

I don't see forward and backward slash as a pair really - they're never used together like that. When forward slash is used as a bracket, such as the original wiki italics identifier, or in regular expressions, it's just a pair of forward slashes, and back slash is used to escape characters in unix, and as the directory separator in DOS. I'm also not sure how / and * are a pair in anything.

Edit: I suppose you'd use \/ to escape a slash in a filename on the terminal, but escaping stuff usually involves a modifier for the backslash then none for the escaped character so they're still not paired IMO.
The characters / and * are divide and multiply on most keyboards - look at the top of the numeric keypad. They're a pair for the same reason + and - are.
 
No time to make changes to the layout ATM, but leaving a note here for comment.

A 'special playback mode'.

If shift-lock, ctrl-lock, alt-lock and fn-lock are all engaged, it is the equivalent of engaging the lid switch. This switches the shoulder buttons into 'playback mode' even if the lid is open. There may be other power saving features that could flip on in this state?

Closing the lid holds this state - opening it holds as long as the 4-lock combo is engaged.
 
_wb_, on 08 Sept 2014 - 06:27 AM, said: Grench, on 08 Sept 2014 - 01:49 AM, said: /**** Multiple Mice oh noes! ****/ Regarding _wb_'s concern about having more than one set of mouse 1 & 2 buttons, that is a non-issue. Anyone who has used 2 mice or an IBM/Lenovo Ultranav keyboard and mouse (3 mice at once), it's simply a non-issue. OK, but how then does a game distinguish shoulder button presses from nub clicks, in case it wants to use those for different game actions? With modifiers you can distinguish e.g. Left Ctrl (SELECT) from Right Ctrl (R1), but how do you distinguish Left Mouse click from Duplicate Left Mouse click? Simple - it doesn't. They're the same button/switch as far as it is concerned. Wire two switches A and B into one circuit in parallel. Put a light at the end. Push button A, light comes on. Push button B, light comes on. Push both, light comes on. Push button A, light comes on, hold it while you push button B, light stays on, release button A, light is still on as B is still pressed. No issue and no need to distinguish between a left mouse click on the red nub pointer in the middle of the keyboard or the one on the trackpad or the one on the mouse. They're all 'Mouse 1' and that switch is either on (clicked) or off (unclicked).
So a game cannot use the nub clicks and the L1/R1 shoulder buttons for different game functions. Seems like an unnecessary limitation to me.

Where the Fn+space=tab on the Pandora is awkward due to the required buttons being next to each other, my keyboard gives two comfortable ways to get the result quickly.
That's one position to take, but then I don't see how you can also say that Shift+Fn+something and similar double modifier combos is somehow easy to do and not awkward. Pressing them in the wrong order is not really an issue, since you do an inward roll anyway.

_wb_, on 08 Sept 2014 - 06:27 AM, said: For international needs, it's best if P+1 and L+2 are available to put other symbols on. One way to do that is by putting not so crucial symbols on those keys, and by don't having any Fn labels on those keys. Then if you want to map P+1, L+2 to e.g. Ü Ö Ä, you can put the original keys at Fn+Ü Ö Ä. This part is confusing to me... Does it have to be P+1 and L+1 or is there a reason why my Fn+G and Fn+H (and Fn+shift+G and Fn+shift+H) that I left open for custom mapping could not work? Or am I misunderstanding the need?
It has to be P+1 and L+2, at those locations. Take a look at a German or Scandinavian keyboard layout to see why.


Alternatively, you could put things at Fn+letter, but then e.g. Fn+U=Ü, Fn+A=Ä, Fn+O=Ö, Fn+S=ß would make more sense than something like Fn+G=Ü, Fn+H=Ä, and Ö/ß missing (or no capital versions of the letters available).

_wb_, on 08 Sept 2014 - 06:27 AM, said: For international needs, some mechanism for dead diacritics is also nice (two key presses, not counting modifiers, instead of three with Compose). Do you have a link describing how this works? I have no point of reference here.
Here are some links to get you started:

http://en.wikipedia.org/wiki/Dead_key

http://en.wikipedia.org/wiki/Diacritic

() {} [] <> /\* <= Yes, 3 as / is involved in two paired sets. +- Which sets of brackets do you use the most? 2nd most? 3rd?
http://mdickens.me/typing/letter_frequency.html lists the following (from most frequent to least frequent):


Punctuation Frequency: , . - " _ ' ) ( ; = : / * ! ? $ > { } [ ] \ + | & < % @ # ^ ` ~
Most important: -

Then: ()

Then: /

Then: < >

Then: { }

Then: [ ]

Then: \

Then: +

So I wouldn't see +- and /\ as a pair like the "real" brackets. Minus and slash are way more important than plus and backslash. Minus is also dash and hyphen (pretty important natural language punctuation symbols), and it's used in operators like "->" © and ":-" (Prolog), while plus is just plus. Slash is used in natural language ("he/she", "n/a", "and/or", dates etc), for division and fractions (1/2, km/h), as a path separator in Unix and in URLs, for comments and regular expressions in several programming languages, while backslash is not used in natural language, is not a mathematical operator, is only used as a path separator in DOS/Windows, and is not very widely used in programming languages -- its main use is as an escape character, e.g. \n for newline, and in TeX.

Of course your mileage may vary and such things depend hugely on your usage pattern.

Edit: Oh, you also had * in that list (I thought it was meant as an asterisk for a "footnote" about /\). Yes, / and * kind of make a pair, but only in the sense of arithmetic and for /* C comments */.

You may also want to consider = as somehow related to < and >, at least in the arithmetical sense (less, equal, greater, also used in combinations =< for leq and >= for geq). Some programming languages also use arrow-like operators like these: =>, ==>, <=, <==, <=>.
 
Last edited by a moderator:
The battery compartment is up-arm from the SoC/Keyboard. The SoC/Keyboard rides closer to the wrist. The whole thing then becomes 1/2 as thick but twice as wide - which is fine.
As soon as you start changing the physical dimensions and move stuff around you open up a lot of possibilities.  You could easily get a battery that is 2 or 3 times the capacity that shouldn't be too bothersome.  That might allow for more constant use, and help power other stuff that is connected (whatever people use, such as cameras).

Wear a long sleeve shirt with over-sized cuffs and 80% of people would never even know you're wired.
I usually wear a dress shirt, or whatever they are called, and typically have the sleeves unbuttoned (I don't like feeling restricted).  The SoC/keyboard module could easily be accessed by rolling up the sleeve.  

An alternative option for the keyboard/input that someone else interested in wearables pointed out to me is the Twiddler. http://twiddler.tekgear.com/

It would make a wearable Pyra more likely if a less one-hand friendly keyboard is selected.  I don't know the dimensions, but if it is small enough to keep in your pocket it might be useful for those willing to make the extra investment.  It isn't my thing, since this whole idea is tied to having a keyboard on your arm for me, which would also allow you to use the gaming controls when not on your arm.  I think major changes to the Pyra/Pandora form would make it less appealing, since it is more about having it on your arm for when you "need" it, and if you are just sitting around you can take it off and play Quake.  I suppose sliding whatever is holding it and the battery on your arm down so it is still usable as a handheld would work well enough.

Maybe we should make another thread about wearable Pyras/Pandoras so we don't keep trashing up your keyboard thread.  This keyboard layout, though, would be a good starting point.

As for the layout, in Fn lock the spacebar becomes tab.  I think this might be an issue if you need access to space/any and numbers or F keys at the same time, but can't identify when that would be atm.

OK - so I may need to go back to paired brackets on neighboring keys with similar Fn/Shift levels. For positioning, it would be handy to prioritize or rank them in order of usefulness.


()


{}


[]


<>


/\* <= Yes, 3 as / is involved in two paired sets.


+-


Which sets of brackets do you use the most? 2nd most? 3rd?


Thanks!
I can only give my best guess of which I personally use frequently, occasionally, and once in a while, and it varies depending on what I am doing:

Frequent

()/-*

Occasional

[]<>\+

Other

{}
 
Last edited by a moderator:
_wb_, on 08 Sept 2014 - 06:27 AM, said: Grench, on 08 Sept 2014 - 01:49 AM, said: /**** Multiple Mice oh noes! ****/ Regarding _wb_'s concern about having more than one set of mouse 1 & 2 buttons, that is a non-issue. Anyone who has used 2 mice or an IBM/Lenovo Ultranav keyboard and mouse (3 mice at once), it's simply a non-issue. OK, but how then does a game distinguish shoulder button presses from nub clicks, in case it wants to use those for different game actions? With modifiers you can distinguish e.g. Left Ctrl (SELECT) from Right Ctrl (R1), but how do you distinguish Left Mouse click from Duplicate Left Mouse click? Simple - it doesn't. They're the same button/switch as far as it is concerned. Wire two switches A and B into one circuit in parallel. Put a light at the end. Push button A, light comes on. Push button B, light comes on. Push both, light comes on. Push button A, light comes on, hold it while you push button B, light stays on, release button A, light is still on as B is still pressed. No issue and no need to distinguish between a left mouse click on the red nub pointer in the middle of the keyboard or the one on the trackpad or the one on the mouse. They're all 'Mouse 1' and that switch is either on (clicked) or off (unclicked).
So a game cannot use the nub clicks and the L1/R1 shoulder buttons for different game functions. Seems like an unnecessary limitation to me.
No more than having modifiers on the shoulders that exist on the keyboard are a 'limitation'.
Where the Fn+space=tab on the Pandora is awkward due to the required buttons being next to each other, my keyboard gives two comfortable ways to get the result quickly.
That's one position to take, but then I don't see how you can also say that Shift+Fn+something and similar double modifier combos is somehow easy to do and not awkward. Pressing them in the wrong order is not really an issue, since you do an inward roll anyway.
Let's pretend you want to press tab. On the Pandora you have two real choices.

1. Roll the right thumb over the Fn key onto the space key - Fn key must be pressed first.

2. Hold the Fn key with the right thumb, move your left hand up and over the keyboard to press space with the left thumb or forefinger.

On my keyboard there are two choices.

1. Press and hold left Fn with the left thumb and then touch the space bar with the right thumb.

2. Press and hold right Fn with the right thumb and then touch the space bar with the left thumb.

The difference between the two keyboards is the timing. On my keyboard the user is expected to chord-key. Think 16th notes in 4/4 time 'da-da'. It should be possible for someone to establish a keying rythm without being interrupted by the modifier keys.

_wb_, on 08 Sept 2014 - 06:27 AM, said: For international needs, it's best if P+1 and L+2 are available to put other symbols on. One way to do that is by putting not so crucial symbols on those keys, and by don't having any Fn labels on those keys. Then if you want to map P+1, L+2 to e.g. Ü Ö Ä, you can put the original keys at Fn+Ü Ö Ä. This part is confusing to me... Does it have to be P+1 and L+1 or is there a reason why my Fn+G and Fn+H (and Fn+shift+G and Fn+shift+H) that I left open for custom mapping could not work? Or am I misunderstanding the need?
It has to be P+1 and L+2, at those locations. Take a look at a German or Scandinavian keyboard layout to see why.Alternatively, you could put things at Fn+letter, but then e.g. Fn+U=Ü, Fn+A=Ä, Fn+O=Ö, Fn+S=ß would make more sense than something like Fn+G=Ü, Fn+H=Ä, and Ö/ß missing (or no capital versions of the letters available).
I looked up a German keyboard. My plain simple response to having P+1 and L+2 keys like that is, "Hell no." That would require the loss and relocation of delete, .,:; and Enter. There are simply not enough keys on the top 2 rows of this keypad layout to do it without completely ruining the keyboard.
German users can map the additional letters to the 4 empty Fn+key and Fn+shift+key spots left open and use compose AND even map letters to mouse 3&4 (shift & Fn included) (secondary shoulder buttons).

_wb_, on 08 Sept 2014 - 06:27 AM, said: For international needs, some mechanism for dead diacritics is also nice (two key presses, not counting modifiers, instead of three with Compose).

Do you have a link describing how this works? I have no point of reference here.
Here are some links to get you started:http://en.wikipedia.org/wiki/Dead_key

http://en.wikipedia.org/wiki/Diacritic
I'll give it a read - thank you.
() {} [] <> /\* <= Yes, 3 as / is involved in two paired sets. +- Which sets of brackets do you use the most? 2nd most? 3rd?
 http://mdickens.me/typing/letter_frequency.html lists the following (from most frequent to least frequent):

Punctuation Frequency: , . - " _ ' ) ( ; = : / * ! ? $ > { } [ ] \ + | & < % @ # ^ ` ~

Most important: -

Then: ()

Then: /

Then: < >

Then: { }

Then: [ ]

Then: \

Then: +

So I wouldn't see +- and /\ as a pair like the "real" brackets. Minus and slash are way more important than plus and backslash. Minus is also dash and hyphen (pretty important natural language punctuation symbols), and it's used in operators like "->" © and ":-" (Prolog), while plus is just plus. Slash is used in natural language ("he/she", "n/a", "and/or", dates etc), for division and fractions (1/2, km/h), as a path separator in Unix and in URLs, for comments and regular expressions in several programming languages, while backslash is not used in natural language, is not a mathematical operator, is only used as a path separator in DOS/Windows, and is not very widely used in programming languages -- its main use is as an escape character, e.g. \n for newline, and in TeX.

Of course your mileage may vary and such things depend hugely on your usage pattern.

Edit: Oh, you also had * in that list (I thought it was meant as an asterisk for a "footnote" about /\). Yes, / and * kind of make a pair, but only in the sense of arithmetic and for /* C comments */.

You may also want to consider = as somehow related to < and >, at least in the arithmetical sense (less, equal, greater, also used in combinations =< for leq and >= for geq). Some programming languages also use arrow-like operators like these: =>, ==>, <=, <==, <=>.
I'm not sure where the hostility towards collecting symbols by their mathematical use comes from. Computers are math - they're just overgrown calculators after all.

I see one use of the Pyra as an Engineering student's secret weapon. Numeric and math/calculator functionality should not be overlooked or glossed over, but embraced as a device feature.
 
As for the layout, in Fn lock the spacebar becomes tab.  I think this might be an issue if you need access to space/any and numbers or F keys at the same time, but can't identify when that would be atm.
Not an issue at all. While you have Fn-lock engaged, yes the space bar is locked into Tab. The Fn-lock (all the locks) work just like 'caps lock' on your keyboard. Hit the modifier key again and it 'back shifts'. Ex: Hit caps lock on your desktop keyboard. Push the A key and get a capital 'A'. Now hold the shift key and push the A key to get a lowercase 'a'.
Similarly, with the Fn-lock engaged, hold Fn with one thumb to temporarily un-Fn the keyboard and push space with the other thumb.

The same would work chording. So, you could shift lock and Fn lock the keyboard then chord shift and Fn with the right thumb and press A with the left thumb to get lowercase 'a', despite the keyboard being in Fn-lock + Shift-lock mode.

OK - so I may need to go back to paired brackets on neighboring keys with similar Fn/Shift levels. For positioning, it would be handy to prioritize or rank them in order of usefulness.

()

{}

[]

<>

/\* <= Yes, 3 as / is involved in two paired sets.

+-

Which sets of brackets do you use the most? 2nd most? 3rd?

Thanks!
I can only give my best guess of which I personally use frequently, occasionally, and once in a while, and it varies depending on what I am doing:
Frequent

()/-*

Occasional

[]<>\+

Other

{}
I'm going to take yours and _wb_'s feedback on bracket usage into account for the next version of my keyboard. It might be a day or two though.
 
So a game cannot use the nub clicks and the L1/R1 shoulder buttons for different game functions. Seems like an unnecessary limitation to me.
No more than having modifiers on the shoulders that exist on the keyboard are a 'limitation'.
Left Shift and Right Shift can be distinguished, they are different keys. Same with the other modifiers. A game or application can do different things with the Left and Right modifiers. E.g. on the Pandora, in say SDL, the SELECT button is known as SDLK_LCTRL, while the R1 shoulder button is known as SDLK_RCTRL. Both behave as Ctrl, but they can be distinguished.


I wouldn't know how to easily distinguish two left mouse buttons. Most software assumes the mouse has one left button and one right button, not a pair of each.

Where the Fn+space=tab on the Pandora is awkward due to the required buttons being next to each other, my keyboard gives two comfortable ways to get the result quickly.
That's one position to take, but then I don't see how you can also say that Shift+Fn+something and similar double modifier combos is somehow easy to do and not awkward. Pressing them in the wrong order is not really an issue, since you do an inward roll anyway.
Let's pretend you want to press tab. On the Pandora you have two real choices.


1. Roll the right thumb over the Fn key onto the space key - Fn key must be pressed first.


2. Hold the Fn key with the right thumb, move your left hand up and over the keyboard to press space with the left thumb or forefinger.


On my keyboard there are two choices.


1. Press and hold left Fn with the left thumb and then touch the space bar with the right thumb.


2. Press and hold right Fn with the right thumb and then touch the space bar with the left thumb.


The difference between the two keyboards is the timing. On my keyboard the user is expected to chord-key. Think 16th notes in 4/4 time 'da-da'. It should be possible for someone to establish a keying rythm without being interrupted by the modifier keys.
I see no difference. If you want to do Fn+Space, in both cases you need to press Fn first and then Space. The main difference is that on the Pandora, you can produce Tab using just your right thumb, while in your layout both thumbs are needed.


So for producing one Tab, your layout is actually worse than the Pandora layout.


For producing more than one Tab, your layout is better since you can hold Fn with one thumb while repeatedly pressing Space/Tab with the other one.


Of course a dedicated primary Tab key is still better. Having Fn at a shoulder button would also help.

It has to be P+1 and L+2, at those locations. Take a look at a German or Scandinavian keyboard layout to see why.


Alternatively, you could put things at Fn+letter, but then e.g. Fn+U=Ü, Fn+A=Ä, Fn+O=Ö, Fn+S=ß would make more sense than something like Fn+G=Ü, Fn+H=Ä, and Ö/ß missing (or no capital versions of the letters available).
I looked up a German keyboard. My plain simple response to having P+1 and L+2 keys like that is, "Hell no." That would require the loss and relocation of delete, .,:; and Enter. There are simply not enough keys on the top 2 rows of this keypad layout to do it without completely ruining the keyboard.

German users can map the additional letters to the 4 empty Fn+key and Fn+shift+key spots left open and use compose AND even map letters to mouse 3&4 (shift & Fn included) (secondary shoulder buttons).
So you propose something like Fn+G for ü/Ü, Fn+H for ä/Ä, L1(Mouse3) for ö/Ö, and R2(Mouse4) for ß?


I don't think German users would be happy with that solution.


How would you feel when you would be given a QWERTY keyboard where the I,O,P keys are missing? No worries, you can map those to Fn+G, Fn+H and Mouse3!


There's a reason why in both my and comradekingu's layout proposals, the P+1 and L+2 keys are either non-essential or can be mapped behind Meta to make room for international keyboard layouts.

There's also a reason why I didn't put any Meta labels at the vowels: in many languages, the additional letters are vowels, so I left those free for custom Meta keys.

e.g. Ü Ö Ä ß € on Meta + U O A S E makes sense for German,

Norwegians could have Ø Å Æ on Meta + O A E,

for Icelandic you could have Þ Ð Á É Í Ó Ú Ý Æ Ö on Meta + T D A E I O U Y W P,

for French you could do à è é ù œ ç on Meta + A E R U O S (or ç at Meta+Shift+C, but then you can't do Ç), and use dead circumflex and tréma for â ê î ô û ë ï ü,

and so on. Those all make some kind of sense. At least much more sense than having to put things at Fn+G, Fn+H, Mouse3 and Mouse4.

I'm not sure where the hostility towards collecting symbols by their mathematical use comes from. Computers are math - they're just overgrown calculators after all.


I see one use of the Pyra as an Engineering student's secret weapon. Numeric and math/calculator functionality should not be overlooked or glossed over, but embraced as a device feature.
Where do you see hostility? I was just pointing out that the main uses of / and - are probably not mathematics for most users. They are of course symbols for division and subtraction, and thus related to multiplication and addition. But they're mostly just slash and dash, used for lots of different things. According to the statistics, dash is the most important punctuation symbol in English text after comma and period (and perhaps apostrophe and quote, depending on the kind of text). On the command line, / and - are pretty much essential. Putting / and - on Shift+Fn+something makes them not very convenient to use. Comradekingu's proposal puts them behind only one modifier, and in my proposal they're dedicated primary keys.

Note that on a standard US-QWERTY keyboard (without a numpad, e.g. on a laptop), / and - are primary keys while * and + are shifted keys. That's not a coincidence. Although if I would have designed it, I would have swapped + and = because the asymmetry between - and + is kind of strange.
 
As for the layout, in Fn lock the spacebar becomes tab.  I think this might be an issue if you need access to space/any and numbers or F keys at the same time, but can't identify when that would be atm.
Not an issue at all. While you have Fn-lock engaged, yes the space bar is locked into Tab. The Fn-lock (all the locks) work just like 'caps lock' on your keyboard. Hit the modifier key again and it 'back shifts'. Ex: Hit caps lock on your desktop keyboard. Push the A key and get a capital 'A'. Now hold the shift key and push the A key to get a lowercase 'a'.

Similarly, with the Fn-lock engaged, hold Fn with one thumb to temporarily un-Fn the keyboard and push space with the other thumb.


The same would work chording. So, you could shift lock and Fn lock the keyboard then chord shift and Fn with the right thumb and press A with the left thumb to get lowercase 'a', despite the keyboard being in Fn-lock + Shift-lock mode. 
I should have been more specific.  If you are playing a game that requires numbers, F keys and space bar frequently it may disrupt game play to hit Fn+Space quickly.  I know you can do it, but if it is a game that needs quick, precise stuff that extra fraction of a second to get space bar, not to mention having your thumbs completely off of the main gaming controls, could be life or death (you know what I mean).

I'm going to take yours and _wb_'s feedback on bracket usage into account for the next version of my keyboard.
I am just one user.  It might help more if others also gave a rough frequency ordering of their use.  There may be people who use {} all the time, and never need the characters I use almost every time I type.

Although if I would have designed it, I would have swapped + and = because the asymmetry between - and + is kind of strange.
That is so you can quickly input 9-0=9 from the number row with one hand, in the event of an emergency, while your left hand/arm/pinky is injured. :p   Yeah, = being the primary character of the key catches me off guard too often when I am not thinking or paying attention.
 
Last edited by a moderator:
I like the idea of "space" being bigger than the other keys and I agree that it is best if it is centered. I have to admit I've never used a keyboard with space being the same size as other keys (even my Nokia E61 with 39 keys had a double space).

After looking at Grench's layout I've came up with a something like this (I've started with Grench's layout and introduced some changes, I haven't thought about F11 and F12 keys, yet, so I've let them remain in place):

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

This layout is not as carefully designed as layouts done by _wb_ or Grench, but I hope it can inspire others to prepare something which will please most of the users
 
Then again keyboards dont have spacebar off center. Do you use the spacebar of the pandora on the right side? Or middle?  I consistently use it left side since it is more central, and when keys are stepped and the size they are, it falls naturally to press within the left box, even though its connected to something bigger.

Curiously putting space dead center and bottom on a two-thumb, isnt "central" in the same sense it is on a 10-finger board.

You are forever windsheild-wiping back and forth to centre for every word you type.
 
Last edited by a moderator:
I've put further keyboard idea development on hold since ED won't even answer basic questions around hardware layout for us. No, I don't blame him. Yes, he's busy with other stuff. I simply don't see any point in continuing development until we know the answers to:

1. Is the prototype case with the double wide bottom right space bar, 'The Version' with no further changes allowed?

2. If we're allowed to manipulate/move the space bar, how crazy can we get? Single width? Move to the left? Move to center? Is any of this 'out of bounds'?

3. Are there any physical constraints of the SoC that we should be aware of that would simply nix some of these ideas?

So - I think we have a lot of great ideas floated - but we're kind of stuck since we don't know which ones to further develop or scrap due to hardware compatibility or lack of.
 
I think ED has indicated that the physical layout is fixed, except for the spacebar: space can be in any position or it can be single-width.
 
1. No, space doesnt have to be a bar key

2. Ideally the most central

3. 9x9 matrix according to the TI spec (corrected, thought it was 8x8 before)
 
Last edited by a moderator:
Back
Top