It's the keyboard layout.


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.
 
Last edited by a moderator:
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.  ;)
 
Last edited by a moderator:
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. ;)
 
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!
 
Last edited by a moderator:
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.
 
Last edited by a moderator:
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.  
 
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? 
 
Last edited by a moderator:
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.
 
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.
 
Last edited by a moderator:
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.
 
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.
 
Last edited by a moderator:
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.
 
Last edited by a moderator:
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.
 
Last edited by a moderator:
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.
 
Back
Top