It's the keyboard layout.

[Neelix]

Last small change, the hardware buttons are now named C1 through C4, being C for custom or OS assignable. I guess they could be made to do anything.

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

Assigning functions to modified modifiers isn't a good idea,  if you do that those modifiers can't be combined.

-Neelix

 

[Eight Bit]

Last small change, the hardware buttons are now named C1 through C4, being C for custom or OS assignable. I guess they could be made to do anything.

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

Assigning functions to modified modifiers isn't a good idea,  if you do that those modifiers can't be combined.

-Neelix

I guess you're saying it's not wise to put a meta function on a macro- or user assignable key? 

Couldn't it be programmed so that the key just farts out the same key scan code as the other keyboard meta instead of keyboard brightness for instance?

 

[Neelix]

Last small change, the hardware buttons are now named C1 through C4, being C for custom or OS assignable. I guess they could be made to do anything.

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

Assigning functions to modified modifiers isn't a good idea,  if you do that those modifiers can't be combined.

-Neelix

I guess you're saying it's not wise to put a meta function on a macro- or user assignable key? 

Couldn't it be programmed so that the key just farts out the same key scan code as the other keyboard meta instead of keyboard brightness for instance?

I'm saying it's not a good idea to put a meta function on a modifier key.  (ie the shoulder buttons)

Lets say i want to press Alt-F4 to quit an application,  so I start by pressing L2+R2... (meta+alt) oops, that's Sysrq...  

I'm sure you can see how this could be a problem.

-Neelix

 

[Eight Bit]

Ah right!

Slight oversight Thanks for pointing it out.

I can do without a sysrq, I will just remove them and update the final proposal thread post.

 

[WizardStan]

Presumably the power button is tied to a hardware interrupt, why not use that as the SysRq? A SysRq on a regular key is no good anyway, it NEEDS to be tied to an interrupt. If the CPU gets so bogged down or the stack gets so corrupted that the keyboard driver isn't working right, having a SysRq on a regular key won't do shit. Putting it on a hardware interrupt line means that no matter what the CPU is doing, the instant you press that key it will do its thing. The interrupt can then poll the GPIOs to figure out what is meant by this particular press, or if it's held for a certain length of time initiate a shut down, and if its held even longer just do a hard power down.

 

[Eight Bit]

Updated:

I also shifted some diacritics around, again. Their placement makes a little more sense now.

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

 

[_wb_]

I do think that having non-primary numbers is an option worth considering, but in my mind, it has one important downside:

it means the layout is not strictly better (that is, better in every single respect) than the Pandora layout.

Since we have more keys available than on the Pandora, it is possible to have a layout that is strictly better: every key that is a primary key on the Pandora can also be a primary key on the Pyra, we just have keys in better positions (number row more reachable), some keys that used to be on the Fn-layer on the Pandora can now become primary keys, and some keys that were not available at all on the Pandora (e.g. üöä) can now become available.

So I want to go back to "numbers on primary keys" for now, and also "no Shift+Fn/Meta symbols", because that also breaks the "has to be strictly better than Pandora" principle (yes, you can argue that Shift+Meta is an "easy mash", but even if the difference is little, it is still worse than just one modifier; "DOSBox compatibility" is an orthogonal issue that should be fixed by fixing DOSBox or with a global input translation daemon).

These are my design principles (and yes, some of those do conflict; the principles are roughly ordered from most important to least important):

• Strictly better than Pandora
• Resemble US-QWERTY
• Backwards compatible with Pandora
• Better spots (less modifiers, easier to reach or find) for more frequently used keys
• Support for English, German, French, Spanish, Portuguese and other European Latin-script-based languages (in that order)
• Functionality above form (not dropping features just to make it look better)
• Efficient to type on
• Easy to learn, simple learning curve, no reference manuals needed
• Geeky features: GREEK and MATH (a bit like the legendary Space cadet keyboard)
• Has to look good (æsthetically)

This is my main proposal:

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

(whether and how those non-ASCII letters ß Ü Ö Ä for German and À È É for French should be labeled is something that can be debated, I'm currently slightly in favor of not labeling them)

Here is a variant with a left-aligned QWERTY row to allow P+1, L+2 remapping:

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

The two above are not new, those are from about a month ago, I just updated the action button labels according to the discussion from the action button label thread.

Here is another variant, with a centered QWERTY row again, but with some interesting changes:

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

• Backspace is moved to the bottom extra action button
• The top extra action button is Delete; Backspace and Del are nicely symmetric, and by putting them on the extra action buttons, they should be somewhat protected against accidental presses (because that's how those extra action buttons are designed) while still being very easy to press (because they're still action buttons, after all)
• Insert at Meta+space (rarely needed key, so no problem to have it only as a Meta key)
• Dash/underscore is now a dedicated key, in its standard US-QWERTY position (this is nice because it is a very important punctuation key, in all use cases: text typing, command line use and coding)
• + at P ("plus"), = at I ("is"); this also puts plus close to minus
• The German letters ÜÖÄß are at Meta+UOAS, which makes a lot of sense
• Spanish Ñ at Meta+N, French/Portuguese Ç at Meta+C, which both make a lot of sense
• The French letters À È É are also labeled, not at A and E because A is Ä already and there is only one E and two accented E's; however all special letters needed for French are clustered (Ç À È É) and the É is also useful for Spanish (like all vowels with an acute accent), so it's nice to have it "clustered" with Ñ.
• If we don't care about macron, we could put F11 at Meta+dash, however for F12 we still need to find a spot then (Enter is an option but I would prefer to avoid that, because there might be games where you want to mix shoulder buttons with Enter without unexpected effects)

 

[lukey]

Is there the possibility to change the behavour of Nub2 to scroll in webpages with it?

 

[TrashyMG]

Is there the possibility to change the behavour of Nub2 to scroll in webpages with it?

there is always a possibility. 

 

[Saber]

Presumably the power button is tied to a hardware interrupt, why not use that as the SysRq? A SysRq on a regular key is no good anyway, it NEEDS to be tied to an interrupt. If the CPU gets so bogged down or the stack gets so corrupted that the keyboard driver isn't working right, having a SysRq on a regular key won't do shit. Putting it on a hardware interrupt line means that no matter what the CPU is doing, the instant you press that key it will do its thing. The interrupt can then poll the GPIOs to figure out what is meant by this particular press, or if it's held for a certain length of time initiate a shut down, and if its held even longer just do a hard power down.

It's a good point you've brought up so I'm curious to know if the keyboard driver isn't working, then how do we utilize any low-level command combos, which is why we'd want SysRq in the first place? 

 

[Urben]

Here is another variant, with a centered QWERTY row again, but with some interesting changes:

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

I like the centered one, the del and backspace idea makes sense and putting insert on meta space is good too.
Did you forgot the € symbol? And You might redesign the "_-" button, I dont get which line is the _ and which is -.

 

[_wb_]

Here is another variant, with a centered QWERTY row again, but with some interesting changes:

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

I like the centered one, the del and backspace idea makes sense and putting insert on meta space is good too.

Did you forgot the € symbol? And You might redesign the "_-" button, I dont get which line is the _ and which is -.

No, € is at ¤ by default, but e.g. if you're in the UK then that key could produce £, or if you're in Japan it could produce ¥. You could even configure it to produce the actual "¤" symbol, or to become a "dead currency key", which you press first and then follow with a letter to get all kinds of currency symbols: e.g.

฿ ¢ ₫ € ƒ ₲ ₴   ﷼ ₭ £ ₥ ₦ ௹ ₰ ₢ ₪  ৳ 元 ₩ ¥   ₳ ₱ ₡ ₯ ₠ ₣ ៛ ₤ ℳ ₦ ૱ ₧ ₨ $ ₮ 圓 円

It is tricky to design a dash,underscore (-_) key using the convention of superscripts for shifted symbols without being ambiguous. The unshifted symbol is dash/minus (-), the shifted symbol is underscore (_), just like on a US-QWERTY keyboard.

Given that the keys are rectangular (unlike normal keyboard keys which are square), it probably makes sense to not use superscripts for shifted symbols, and then you would get 1! 2@ 3# 4$ 5% 6^ 7& 8* 9( 0) -_  which is less ambiguous.

 

[Grench]

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).

To get to your single shift or single Fn key though, you have to give up a lot of things that may not seem obvious on the surface. You're giving up symbol pairs - which directly breaks compatibility with DosBox and many of the PC gaming things that are coming down the pipe. Emulated PC gaming, both X86 Linux and X86 DOS is going to be a huge thing with the Pyra. The keyboard needs to be ready to support that properly. Broken shift pairs doesn't work well with that. Having numbers and F1-F12 on the same physical keys and not accessible at the same time doesn't work well with that.

You brag about having - _ = + { [ ] } \ | : : ‘ “ < > / ? on only one modifier, but neglect to mention that I have the roots for all of those as ROOT KEYS, no modifier - and the others I have MATCHED to their shifted pairs, and even those are only on one modifier. They're not pushed to the Fn layer of some random key, they're ON their OWN key with their paired symbol.

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

{ doesn't belong on Fn+W. { belongs on shift+[.

You have ~ on Y and ` on N. I have a `~ key. Added bonus, people who need or care can use Fn+ that key to drive dead key diacritics without having to guess or search.

Moving the numbers to the Fn layer is BETTER than moving the rest of the symbols to the Fn layer. Numbers are in a logical order - they're easier to find and can even be 'counted' to find in the dark.

So, in my humble opinion, you gave up a LOT to have those numbers on the top layer. I like numbers, but I like them a lot more when they're on the same Fn layer as F1-F12 AND freeing up space for the punctuation and bracket keys AND getting simple diacritics AND retaining symbol key pairs AND become capable of making a 33 key PC gaming control pad at the push of two buttons without loosing any letters AND while in Fn-Lock (gaming) mode, the Esc key becomes top-level (dedicated).

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.    

3 shift keys is a complete waste - and why on earth would left be on the right and right on the left and right exists twice...? Logic fails.

 

[Neelix]

Given that the keys are rectangular (unlike normal keyboard keys which are square), it probably makes sense to not use superscripts for shifted symbols, and then you would get 1! 2@ 3# 4$ 5% 6^ 7& 8* 9( 0) -_ which is less ambiguous.

Less ambiguous?  I disagree. I reckon we should keep the superscript for shifted symbols convention.

-Neelix

 

[_wb_]

Given that the keys are rectangular (unlike normal keyboard keys which are square), it probably makes sense to not use superscripts for shifted symbols, and then you would get 1! 2@ 3# 4$ 5% 6^ 7& 8* 9( 0) -_ which is less ambiguous.

 
Less ambiguous?  I disagree. I reckon we should keep the superscript for shifted symbols convention.


-Neelix

I meant: less ambiguous specifically for the key "-_". Since the main difference between minus and underscore is their position, it is hard to tell which is which if you use the superscript convention. In fact, doing superscript on underscore brings it roughly to the level of minus, or even lower, depending on which symbol exactly you use for the dash key: hyphen (‐), en dash(–), em dash (—), minus (−), or hyphen-minus (-).

So for clarity it might be better to use a double (nested) superscript, or does that make it even worse?


One superscript:    -_ 


Two superscripts:   -_


No superscript:       -_

 

[Grench]

I suspect you may be seeing only one side of this coin. The Pandora's layout is a broken compromise. The symbol key pairs are all broken and the symbols themselves are scattered around pretty much at random in order to make them fit on the Fn layer. The shift and Fn buttons are on opposing sides, making chording them difficult. Yes, we can and should do MUCH better than the Pandora. Fixing this symbol pairs breakage and allowing keys to hold a more natural position should be paramount.

I do think that having non-primary numbers is an option worth considering, but in my mind, it has one important downside:

it means the layout is not strictly better (that is, better in every single respect) than the Pandora layout.

I do think that having primary numbers is an option worth considering, but in my mind it has one important downside:It means the layout is not strictly better (that is, better in every single respect) than the Pandora layout. It forces the symbol pairs to break and assignments to be randomly scattered on the Fn layer JUST LIKE THE PANDORA, resulting in us repeating the same mistakes.

Since we have more keys available than on the Pandora, it is possible to have a layout that is strictly better: every key that is a primary key on the Pandora can also be a primary key on the Pyra, we just have keys in better positions (number row more reachable), some keys that used to be on the Fn-layer on the Pandora can now become primary keys, and some keys that were not available at all on the Pandora (e.g. üöä) can now become available.

Since we have more keys available than on the Pandora, it is possible to have a layout that is strictly better: every key that had it's pairs split and scattered aorund on the Pandora can be a primary key on the Pyra, we just have keys in better positions (symbol keys more reachable), some keys that used to be on the Fn-layer on the Pandora can now become primary keys, and some keys that were not available at all on the Pandora (e.g. üöä) can now become available.

So I want to go back to "numbers on primary keys" for now, and also "no Shift+Fn/Meta symbols", because that also breaks the "has to be strictly better than Pandora" principle (yes, you can argue that Shift+Meta is an "easy mash", but even if the difference is little, it is still worse than just one modifier; "DOSBox compatibility" is an orthogonal issue that should be fixed by fixing DOSBox or with a global input translation daemon).

So I want to stick with "numbers on Fn" for now, and retain the logical "Shift+Fn/Meta symbols" on the number row, because that allows us to make a layout that "is strictly better than Pandora" principle (Shift+Meta is an "easy mash", but even if the difference is little, it is still BETTER than having the symbols broken up and scattered around; "DOSBox compatibility" is hardware issue that should be fixed by ensuring our keyboard mapping matches the DOSBox, QEMU, etc. convention. It is EASY to do IF we allow the number row to be on the Fn layer..

Layouts like this:

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

are far -better- than the Pandora layout -because- of what it allows on the symbols keys that the other layouts want to break up and scatter.

~ should be on shift+`. They should share a primary key labeled `~ such that Fn+`~ is the related diacritic. This same rule should apply to all of the 'native' symbol pairs on a US standard keyboard:

`~

-_

=+

[{

]}

\|

,<

.>

/?

Symbols are more used than numbers.

Symbols are more likely to be used in sets of 1-2 where in other layouts it is modifier+symbol then release both.

Numbers are more likely to flow in longer strings where in this layout it is modifier+numbernumbernumber... then release. The modifier only has to be depressed once for a long string of numbers.

Symbols have a logical 3rd+4th layer Fn+key definition as dead key diacritics.

The numbers 1234567890 should be available top side at the same time as F1-F12 for gaming. Having them both on the Fn layer allows them to be Fn-locked to the forward layer at the same time. This effectively makes a 'game mode' where the Pyra will have:

D pad (4)

Nubs (2)

Right game pad (6)

Numbers 1-0 + Ü (11)

F1-F12 (12)

For a total of 12+11+6+2+4 = 45 key game pad ideally situated and set up for PC gaming on the Pyra.

Clearly we should emphasize having the symbol pairs retained for greater software compatibility AND easier diacritics AND faster typing AND faster coding. The fact that in the process we also gain the most awesome game layout ever seen - that's just a real big bonus.

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

 

[Saber]

So, in my humble opinion, you gave up a LOT to have those numbers on the top layer. I like numbers, but I like them a lot more when they're on the same Fn layer as F1-F12 AND freeing up space for the punctuation and bracket keys AND getting simple diacritics AND retaining symbol key pairs AND become capable of making a 33 key PC gaming control pad at the push of two buttons without loosing any letters AND while in Fn-Lock (gaming) mode, the Esc key becomes top-level (dedicated).

 

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.    

3 shift keys is a complete waste - and why on earth would left be on the right and right on the left and right exists twice...? Logic fails.

I've said this before that not everyone who will buy a Pyra will use it to code, or play MORPG/DOSBox games, and I haven't given up anything by retaining numbers as primary. They are primary on keyboards because they are used by most general users quite often, yours truly included.

My layout though is viable even with one keyboard Shift key. It is up to ED to decide if he wants to keep two of them, and I hope that he does for symmetry, but as I've explained, with one Left Shift key placed on the right side half, we are given an opportunity to remap this key to anything we want as an owner should we choose to, and those who don't use the shoulder button Shift can have an easy time of forming capital letters while texting. Again, if ED says he wants only one keyboard Shift, then Left Shift will move back over to the left side, CAPS would then become Fn + L.Shift, and we have another key, unassigned as of yet and maybe to Compose, over on the right to play with. That's if he says he wants only one keyboard Shift, which I hope he doesn't.  :mellow:

As for symbols in my layout under Fn(Meta), with one of these modifiers on a shoulder and the other on the opposite side with the keyboard, it should be a breeze to output them, but again as I've repeated, with two keyboard Shifts, the as you say redundant one on the right side(Left Shift) could be remapped to any primary key the user may choose after ownership.   

 

[Saber]

I suspect you may be seeing only one side of this coin. The Pandora's layout is a broken compromise. The symbol key pairs are all broken and the symbols themselves are scattered around pretty much at random in order to make them fit on the Fn layer. The shift and Fn buttons are on opposing sides, making chording them difficult. Yes, we can and should do MUCH better than the Pandora. Fixing this symbol pairs breakage and allowing keys to hold a more natural position should be paramount.

I agree some of the Pandora layout is a mashup but I don't think removing the numbers as primary is an improvement over it. In my most recent layouts in my sig, symbol pair arrangements are better, brackets { [ ] } in particular. Symbols for - + = _ as well are in more effective locations too. 

 

[Urben]

I meant: less ambiguous specifically for the key "-_". Since the main difference between minus and underscore is their position, it is hard to tell which is which if you use the superscript convention. In fact, doing superscript on underscore brings it roughly to the level of minus, or even lower, depending on which symbol exactly you use for the dash key: hyphen (‐), en dash(–), em dash (—), minus (−), or hyphen-minus (-).

So for clarity it might be better to use a double (nested) superscript, or does that make it even worse?

One superscript:    -_ 

Two superscripts:   -_

No superscript:       -_

Why not make - the shifted key? Its easier to identify the _ if its actually at the bottom, which is possible when being primary.
_- or _-

EDIT: Oh I see its like you do on the default qwerty layout...

 

[Saber]

^

I think - and + should be on the same primary, Shift or Fn level.