It's the keyboard layout.

[WizardStan]

You have not demonstrated a "problem". Only traced the events, which as far as I can see don't justify this risk spoken of if we have two Right Shifts on the Pyra

Then I haven't adequately explained the problem. Sorry, this is my fault.This is the problem: if you hit both at the same time and then release one there is a potential that an application listening for keydown/keyup events, unaware that there are in fact two keys with the same sym, will simply consider the key as released. The problem then is that you are still holding the other key but the application, whatever it may be, does not recognize that it is being held.

I'm sorry, I thought walking through the events leading to the problem made the problem self evident. Does this explain things well enough now?

 

[Saber]

You have not demonstrated a "problem". Only traced the events, which as far as I can see don't justify this risk spoken of if we have two Right Shifts on the Pyra

Then I haven't adequately explained the problem. Sorry, this is my fault.
This is the problem: if you hit both at the same time and then release one there is a potential that an application listening for keydown/keyup events, unaware that there are in fact two keys with the same sym, will simply consider the key as released. The problem then is that you are still holding the other key but the application, whatever it may be, does not recognize that it is being held.


I'm sorry, I thought walking through the events leading to the problem made the problem self evident. Does this explain things well enough now?

No need to resort to that tone. It's not clever nor through it's contrived humility does it show maturity.  

It's the risk potential here I consider trivial and not worthy of being a "problem", more of a nuisance, if it ever is realized in execution.   

 

[WizardStan]

No need to resort to that tone. It's not clever nor through it's contrived humility does it show maturity.

Sorry, I'm not trying to be clever. I genuinely thought you didn't understand what I'd said. This happens a lot with me, I'll explain something and it makes sense to me but the person I'm talking to just doesn't get it, so I need to try again. One of the things I hate is a bad argument and if you can't explain something simply enough that the other person understands it (whether they agree or not is besides the point) then it is a bad argument, thus I correct myself whenever possible.

It's the risk potential here I consider trivial and not worthy of being a "problem"

It's demonstrable risk. Whether you think the risk is low enough to consider trivial or not is irrelevant. It exists, can definitely happen, and is therefore, by definition, problematic.As I said, I also agreed that it's such a low risk that we shouldn't really worry about it but at least acknowledge that it is a problem. If you're going to be introducing problems, no matter how insignificant, they had better come with enough features to compensate.

As Neelix said, though, in addition to this risk of missed key presses there's also the problem of taking up a precious key which could be used for something else.

 

[comradekingu]

For me its not even the missed key, its the problem of not doing anything useful. For case of argument the backspace from colemak is a better key. The familiarity is only something that steals efficiency, because its implying that two thumbs are 10 fingers, in a way that it isnt.

When i tried the three altGrs and looked at the things it produced, i was able to nest them within eachother, up until a point. I suppose thats fine since its always singular altGr. It looked like it wasnt possible to truly have both at the same time. Could test with neo, since that has modifiers that arent strung together like shift+altGr is. But i think unless you make multiple layers of the same modifer into something new, it will just be the same you started with.

Todays tidbit shared from IRC

TrashyMG|Work: the Pyra shoulders are on gpios separate from the keyboard matrix, one cool thing that could be done is that they could be put into a gamepad button mode

TrashyMG|Work: actually all the game buttons except for the two smaller game buttons have dedicated gpios

TrashyMG|Work: the two smaller ones are on the keyboard matrix.

Me and wb confirm, along with someone I talked to that proposed this from a developer point of view.

And if your thing isnt games, an always mediabuttons mode, or just a mediabutton mode in general, would be sweet.

High end media devices sell for lots of money, here you can connect your own usbdac and amp. No other thing provides that in a small laptop. For me thats on par with games with photography on a nice second.

 

[_jr_]

It's the risk potential here I consider trivial and not worthy of being a "problem", more of a nuisance, if it ever is realized in execution.

You are obviously entitled to your opinion, but have until now failed to demonstrate that it is relevant or even informed. That you cannot see a serious problem may well be a deficiency on your side. Perhaps considering that some are intending to run closed source software (with or without emulation) that canot easily (if at all) be modified to cater to arbitrary design decisions makes it easier to understand where actual problems could arise. This applies equally to so called dosbox compatibility.

 

[comradekingu]

Dosbox is gpl, as for closed source software, lets first estimate the problem. If there are primary labels as per US layout, thats most of the problem solved. A huge step up from the pandora, where i cant recognise the order from anywhere.

As for secondary labels, where is the problem felt? Not just in general, but when it comes down to it. People being able to have as many dead-diactrics as possible is a very real issue, and it has to do with language.

I think that is a primary concern over learning where secondary labels are, but please substantiate further.

If you are able to run your closed source thing and it accepts input, technically you can put a level of arbitration on the input layer. Which gives you the option to also rectify the problem that arises when a game has decided position between the secondary labels is important.

 

[Saber]

It's the risk potential here I consider trivial and not worthy of being a "problem", more of a nuisance, if it ever is realized in execution.

You are obviously entitled to your opinion, but have until now failed to demonstrate that it is relevant or even informed. That you cannot see a serious problem may well be a deficiency on your side. 

That is your opinion as well which is as uninformed as mine as you say since it hasn't been "demonstrated", as I have asked it to be several times, in practice on real hardware. Call it thoroughness. I understood WizardStan just fine and I consider this "problem" again as insignificant and another one of those blowing it out of proportion conditions this forum and some of you in your compulsions are famous for.

When the Pyra ships with two keyboard Shift keys with one of those mirrored on the L1 Shoulder button, then you can moan and groan about how you saw this deficiency coming but no one payed heed to your insights. The rest of us will enjoy our machines. 

 

[_wb_]

Saber, your style of argumentation kind of bothers me. Here is a Saber-style argument for dropping the Q key:

Not a lot of people regularly write words that contain the letter Q, and even if they do, nobody stops them from remapping one of the various Shift keys to "Q". Also, I have asked many people to physically (or even just in software!) remove the Q key from their keyboards to "demonstrate" the "problem", but none of them have actually done this, in practice, on real hardware. Call it thoroughness. I understand your counter-arguments just fine, but I consider this "problem" as insignificant and another one of those blowing it out of proportion conditions this forum and some of you in your compulsions are famous for.

When the Pyra ships without the letter Q labeled, then you can moan and groan about how you saw this deficiency coming but no one paid heed to your insights. The rest of us will enjoy our machines.

 

[WizardStan]

uninformed as mine as you say since it hasn't been "demonstrated", as I have asked it to be several times, in practice on real hardware. Call it thoroughness

It's not thoroughness, it's pedantry. The risk has been demonstrated logically without needing to be physically done but because it hasn't *actually* been done you are refusing to accept it. I could apply your exact same argument to a lot of things that obviously make no sense but refuse to accept them unless someone actually demonstrates a failure.This is the kind of argument that anti-vaxers use to explain why they don't think their kids need vaccinations. It's a bad argument.

edit: example provided by _wb_. Thanks!

 

[comradekingu]

The real issue went without mention, the one that isn't just potentially problematic. How shift on the left is bad has been demonstrated and argued. Also here the burden of proof is with the person proposing it. Referencing ED when largely the people designing keyboards agree and do present reasonable arguments, is not a meaningful contribution to discussion.

The purpose of the shift is primarily threefold. 1 type big letters 2. type symbols 3 type 4th level modifer along with AltGr

Notice the three fade in relevance 1 is more important than 2 is more important than 3.

Big letters are only typed after space and enter, so it should be close to those, which can only be on the right.

There is another way to get efficiency too, its to make both hands do more at once, it seems practical, but what its really doing, is tying both hands up at extreme left and right. It also slaloms motorical attention and visual focus. Instead putting all on the right, which is also good for efficiency since its the dominant hand, means you are free with the left to start a sentence. You are free to start a sentence with the right thumb too, if you shouldershift.

Advanced and newcomer alike, it works. Putting it here also provides an avenue of opportunity to get an extra letterkey on the keyboard for the languages that need 4 instead of 3.

There is no meaningful effect of having the left side shift for typing symbols on the right. Since for that shouldershift is better. And if the shift on keyboard is dead, this argument is further weakened.

 

[Saber]

Saber, your style of argumentation kind of bothers me. Here is a Saber-style argument for dropping the Q key:

Not a lot of people regularly write words that contain the letter Q, and even if they do, nobody stops them from remapping one of the various Shift keys to "Q". Also, I have asked many people to physically (or even just in software!) remove the Q key from their keyboards to "demonstrate" the "problem", but none of them have actually done this, in practice, on real hardware. Call it thoroughness. I understand your counter-arguments just fine, but I consider this "problem" as insignificant and another one of those blowing it out of proportion conditions this forum and some of you in your compulsions are famous for.

When the Pyra ships without the letter Q labeled, then you can moan and groan about how you saw this deficiency coming but no one paid heed to your insights. The rest of us will enjoy our machines.

Maybe you can add this fabrication into your chart(s).

For the uninformed, I never said the above nonsense. It's one of _wb_'s usual tactics. 

uninformed as mine as you say since it hasn't been "demonstrated", as I have asked it to be several times, in practice on real hardware. Call it thoroughness

It's not thoroughness, it's pedantry. The risk has been demonstrated logically without needing to be physically done but because it hasn't *actually* been done you are refusing to accept it. I could apply your exact same argument to a lot of things that obviously make no sense but refuse to accept them unless someone actually demonstrates a failure.
This is the kind of argument that anti-vaxers use to explain why they don't think their kids need vaccinations. It's a bad argument.


edit: example provided by _wb_. Thanks!

I accept it but as a minuscule problem that most people will never notice or be troubled by it.  

 

[codifies]

I accept it but as a minuscule problem that most people will never notice or be troubled by it.

Your evidence for this supposition is?

 

[Saber]

I accept it but as a minuscule problem that most people will never notice or be troubled by it.

Your evidence for this supposition is?

I didn't think verifiably recurrent evidence was needed from either side. 

Honestly, if it becomes an attentive issue, ED will take care of it in his final layout. If it's a non-issue, he'll treat it as such. What do you expect to happen? 

 

[_wb_]

Having three shifts and thus either two Left_Shifts or two Right_Shifts is a mild problem. It would be a Pyra-specific thing that brings us further away from normal keyboards. The bigger problem is that one complete key is wasted: I say a "complete" key because Shift should not have Meta/Fn mappings, and no Shift mappings either, so it's not just a key wasted on the primary layer, but also on all other layers.

It can be justified to create problems and waste keys if the benefit gained from that is large enough. However, a third shift does not add any benefit at all for most users: many Pandora users don't even use the one keyboard shift. In handheld mode, the shoulder buttons are a superior input method for modifier chording. In tabletop mode, two fingers from the same hand can be used to chord shift with keys on the same side, so an extra shift is not really needed here either. The only use case in which a third shift is useful, is handheld mode thumb-only typing, for people who don't want to use the shoulder buttons for whatever reason.

From a point of view of ergonomics and efficiency, there are better arguments in favor of adding a second "space" key on the left, or even an extra letter "E" key on the right.

 

[comradekingu]

It only tricks users into the habitual use of shift on the left, when that is less efficient due to tying up your thumb there. Distance travelled is very important on a two-thumb keyboard, you have a concept of dead-time introduced because you cant have the same reach as you do with two full hands.

The need for left side shift is only felt when you put the comma and dot on the left, which is the wrong side with respect to enter.

The same way you tie up both hands at extreme positions with everything else on the right, and only redundant shift on the left, or comma and dot on the left, you are doing it in that case with the right hand on enter and the left on redundant-shift.

I understand now why the layout in firstpost cant be questioned, saber didnt make it from scratch, its just the pandoralayout with some improvements (US numberrowsymbols, dedicated tab) because of the extra buttons.

It doesnt fix any of the important issues, and its far removed from a real keyboard. It creates a new problem by naming a button AltGr and mixing that with F-keys, symbols moved to letters and international language support. This is problematic because symbols with AltGr is expected at thirdlevelshift numbers, not F-keys, there are missing symbols, and you cant fit in either regional altGr alternate graphics, nor a full set of interlingual support.

The pandora keyboard can be excused for being what it was due to lack of keys.

Bringing legacy along onto something that has enough keys to do it right, is a waste of a keyboard.

It doesnt work for more people, its a little better for all, but it is fundamentally flawed for the exact same reason a pandora-keyboard doesnt work well, is lackluster for english users, and is broken for international users.

 

[bzar]

I can't provide quantitative, objective evidence, so I'll settle for a qualitative, subjective opinion: two physical buttons indistinguishable in software is ugly and a waste of a button.

Now a couple of facts: The other can't even be remapped if they literally work as the same key. Even if they were to produce different keycodes to allow remapping, doing said remapping would break any pyra-customized software that depends on both shifts existing on the keyboard.

 

[comradekingu]

Because you are trading away what is in software the left shift. If you have two, the physically righthand shift could be software-wise left shift, since you would want to swap out the other one, but that is just weird.

 

[Saber]

I can't provide quantitative, objective evidence, so I'll settle for a qualitative, subjective opinion: two physical buttons indistinguishable in software is ugly and a waste of a button.

Now a couple of facts: The other can't even be remapped if they literally work as the same key. Even if they were to produce different keycodes to allow remapping, doing said remapping would break any pyra-customized software that depends on both shifts existing on the keyboard.

I was under the impression two physically different keys had two different scan?/keycodes and may, as in the case of two Right Shift keys, carry the same assignable keysym(both Right Shift). Kind of like two houses(L1 and whatever a keyboard's Right Shift key location is) in the same neighborhood(Pyra) with two distinct families living in each. With two Right Shifts it would be as if two houses in this neighborhood are shared by the same family at the same time, unless they move out of one of them and sell it to another family. This selling is the remapping from say the Right Shift on the keyboard to the Yen. 

When you say break what does this mean will occur, from a guessing undocumented standpoint? 

Regardless, it's an easy fix in my layout by several means but I'm curious first about what I posed above.

 

[comradekingu]

If by several fixes you address the problem in different ways, you haven't fixed the whole, nor answered for the decision of implementing the a left side shift, all combinations thereof are problematic, as documented.

Its on you to both clarify and test out any issues, and that's after the real issue is dealt with, a left side shift is useless.

Edit: The full lowdown is here. If you understand that, we will most probably agree (like the rest of us do) before getting into semantics.

 

[Saber]

Anybody else?