...in favor of a third Shift key, after reading all arguments pro and contra? Nope, I don't think so.Anybody else?
...in favor of a third Shift key, after reading all arguments pro and contra? Nope, I don't think so.Anybody else?
I posited two possibilities: the two right shifts share a key code (in addition to the key sym) or they do not. If they do, they can't be differentiated outside the keyboard driver. If they don't they can, but that leaves the mentioned subjective issues.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.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.
This assumes the person using the layout has the same subjective standpoint I hold, namely that two right shifts is "ugly and a waste of a button". The person then proceeds to change the layout to make the second right shift something more useful. This has the same issue as any primary key function overmapping. Assume a software uses the keyboard right shift to invoke some action (like opening a menu) not because of its role as a shift key, but because of its location on the keyboard. The person now can't use the key as intended by the software developer, because the key has been overmapped with something else.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.
Well, the burden of proof is usually on the person making a claim, which originally was "two right shifts cause issues". That said, I think the logical evidence provided by WizardStan is enough to shift it (pun not intended). The latest claim in this chain was something akin to "the probability of the issue of two right shifts manifesting is neglible". This has since been disputed, but the burden of proof sticks with the person making a claim.So... evidence is not needed so long as you are the one challenged to provide it to support your own results, but the rest of us have to provide evidence to prove... sorry, got lost in your supreme logic.
Inventive and evolutionary, or crazy.I like the idea of Esc on the main keyboard. That's pretty inventive, Saber!
True, this is always a worry with Escape. If only we knew it could be up in the rafters where you have it in your layouts. As far to the left edge as we can go will have to do in this waiting moment, till we know.I'm a bit worried about accidental Esc presses if it is over there...
The original claim was implicit in the form of a keyboard layout proposal that had 3 shifts (that this would work properly).Well, the burden of proof is usually on the person making a claim, which originally was "two right shifts cause issues". That said, I think the logical evidence provided by WizardStan is enough to shift it (pun not intended). The latest claim in this chain was something akin to "the probability of the issue of two right shifts manifesting is neglible". This has since been disputed, but the burden of proof sticks with the person making a claim.So... evidence is not needed so long as you are the one challenged to provide it to support your own results, but the rest of us have to provide evidence to prove... sorry, got lost in your supreme logic.
I appreciate your input here but I have doubts about your blanket assumption. In v4.0a, the Escape key is placed as far as possible to the left border, out of the way, and the Tab key is in the same location as yours confidently is placed in your last updated layout.Putting Esc where Tab usually is really feels like a recipe for "oops" moments, almost like putting Del where Enter usually is. You wanted to open that file? Oops, you just deleted it. You wanted to go to the next field of the form? Oops, you just closed the dialog.