It's the keyboard layout.


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

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

The subjective points are not worth arguing about, as they're very much just opinions. For anyone holding those opinions, the presented facts are an issue. For pretty much anyone else they will seem like non-issues. The severity of the issues or potential ways to mitigate them assuming one of them manifests can be debated. Also the probability of the issue manifesting within the first group can be estimated.
 
Thanks B-ZaR.

Here's two WIP layouts. One is with a solitary keyboard Shift and the other with two of them. 

v4.0a(one keyboard Shift)

http://i.imgur.com/mut8c3z.png

mut8c3z.png

v4.0b(dual keyboard Shifts)

http://i.imgur.com/UmsBnb4.png

UmsBnb4.png
 
For English users:  There are German symbols

For German users: There are no German keys

For everyone else: There is not even a second rate way of typing, and Fn is not how anyone expects to type diacritics.

, and . are on the wrong side of the keyboard for everyone.

BXYA layout is activly incompatible with any and all current conventions.

I cant for the life of me see how this works for the most people. I cant see how its even optimally attainable levels for anyone. Its still the pandora layout.
 
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.
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.
 
Last edited by a moderator:
@B-ZaR - proof is a negligible issue therefore you argument is refuted and has as turned into a nice red and white striped box of popcorn !
 
I like the idea of Esc on the main keyboard.  That's pretty inventive, Saber!
Inventive and evolutionary, or crazy.  :)

I'm a bit worried about accidental Esc presses if it is over there...
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.  :)
 
as an old friend used to say, "I'm not afraid."  i don't think you'd hit it accidentally too many times, but i do like how it's more accessible than something up top.
 
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.
 
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.
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.
The original claim was implicit in the form of a keyboard layout proposal that had 3 shifts (that this would work properly).

I agree that the logical evidence provided leads to the conclusion that three shifts is a bad idea both in general and specific to the reasons listed by WizardStan.

For Saber to demand others to defend his own claims then resort to insults when others decline to do his work for him is simply inappropriate and should be called out.
 
I don't think esc/tab is as bad as delete/enter, so that's a bad comparison to make.
 
I agree that Esc/Tab is not as bad as Del/Enter (I said "almost as bad", so less bad). But Esc and Del can both be "destructive" keys (with connotations of "abort/quit" and "remove"), while Tab and Enter are both "innocent" keys, used for whitespace and navigation, usually with an easy way to undo.
 
I should probably abort/quit more often than I intend to, so that's not a bug, it's a feature.
 
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.
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.   

I'm flexible though and my ideas are hardly the word of gospel so we could move things around a bit: Tab and the Comma key could be interchanged if it comes to it or we could put Escape up where you have it, or on Fn + q again so another key is gained. We may even do something eccentric with v4.0a, musical chairs like, and move Left Shift over to where Tab is, Tab up to Escape, Escape up to the number one(and walk the numerics over by one key to the right), Backspace then to Enter, and Enter down to Left Shift(where Enter is normally anyways). Options to mull on. :)     
 
Here's v4.0c as described in the post prior to this: 

(layouts v4.0a and v4.0b are in my sig)

Kind of like this one. 

RNDtSdH.png
 
Last edited by a moderator:
Back
Top