It's the keyboard layout.

[comradekingu]

http://www.dosbox.com/DOSBoxManual.html

http://www.vogons.org/viewtopic.php?t=21824

http://www.dosbox.com/wiki/KEYB

 

So we know it doesnt have to be solved by letting it dictate the layout.

If we consider the issue of why dosbox-default is bad to be solved by doing it one way, then we are forgetting what the issue was, counting our blessings, and not looking at the downside of doing things that way.

There is no forced determinism, but there are real consequences.

It has implications on dead-key diactrics, button placement, efficiency, perception etc etc. It is not at all irrelevant to user-friendliness or functionality as a whole, for more people. If you dont solve that, you arent solving anything for anyone.

A real argument is that US pairs are better for US-people, but going with that, we arrive at wbs point that going down that path caters and then centers around one default, known to some.

So what is the result? Have you tried that on any users of US-layout? I use US layout (historically and more often due to badly coded software) enough to know how to do it. I havent used it enough to develop a theoretical level of arbitration that i can employ to it, i just know how the buttons work.

Whenever you say US-layout, and its for all intents and purposes, only different for the one change you have in mind, you are pushing a whole lot of users in front of you that may or may not agree.

http://www.keyboard-layout-editor.com/#/layouts/a08aaddd5f8bff6bce928661ed411158 is as close to US layout anyone has gotten. But its not user-friendly. No. It looks needlessly complex (because it is) and it looks cramped.

Where the games got old and hacks came in to solve matters, the US layout actually persisted, and is now ingrained in all things. That has its upsides too. 

Consider the shifted numberrow, its all used for something, even poundsign #.  So it makes sense to do that, in the arrangement US-people are used to.

Ironically, if you hack the keyboard to work with badly coded software, its the real US layout that comes to bite you.

With US not having third level modifiers on numbers, if you really want to go further, you need a way to offload that burden. Its a whole lot of symbols that need to go somewhere.

If we look to the real US layout, we dont have all the full layout keys, we dont even have the full numberrow to begin with. So you end up putting symbols on letters, which has _nothing_ to do with US layout. It is so far removed from things keyboard, it ends up as toy-keyboard, regardless of other changes. And im not saying its a toy-keyboard compared to something, im saying thats what a toy keyboard is.

Another alternative to offload symbols is to do away with dedicated numbers, and put all the full layout buttons on the bottom row, as dedicated buttons. You have then changed premise of what makes a keyboard work, position.

Also, doing it that way, it would make sense to move the space, so you end up moving to africa to afford to build a better igloo.

TL;DR Before we get high and mighty about bannering the parole of US-layout, we need to make sure it looks like a keyboard and works like a keyboard, that people can use and understand.

 

[WizardStan]

http://www.keyboard-layout-editor.com/#/layouts/a08aaddd5f8bff6bce928661ed411158 is as close to US layout anyone has gotten. But its not user-friendly. No.

And what about all the others doing US layout style punctuation pairs? Did you forget them?You've arbitrarily picked a layout you personally deem closest to US layout and then arbitrarily decided that you personally do not consider it user-friendly and used that as an argument against punctuation pairs. It's a bad argument. If that's the direction you want to go you need to explain why that layout is more US layout than any other, why it isn't user friendly in a way that can't be used against other layouts and cannot be obviously fixed, and then why that's relevant to the discussion at hand.

 

[comradekingu]

The point is it cant be both. "It is the US layout" is an unattainable goal.

It cant even be pairs and US international, which is much of the reason why US layout has a value outside of its comparative userbase.

If you do number-row with standard US shifted symbols, then some of them wont have press invoker+ that key+ letter you want to modify.

If there are no AltGr third level shifted symbols on number-row, it means some of them go unused.

There simply isn't enough other buttons, like on a US keyboard, for that to add up.

Edit: The extreme you would have to go to make it happen is absurd, and nobody is pretending it isn't. So lets stop pretending pairs
and US-layout is something that makes sense. We need to look at downsides.

We need to look at what we have in terms of buttons, demographic, and potential. Writing potential, usage, and coding. And the people
we are selling to.

User familiarity and in some sense programs / coding paradigms of the US number-row go hand in hand.
It isn't wasteful, it doesn't go away, and a lot of people are familiar with it as a bonus.

Lets not forget any further steps are incompatible with
itself, as mentioned, so that line of thinking stops there. If you try to please those people more, you ruin things for everyone else.

The whole premise of "we (US/UK) use the full layout for symbols" feel free to use it for something else that you need", is lost.

That is important to everyone, and it works for writing and coding.

 

[WizardStan]

The point is it cant be both. "It is the US layout" is an unattainable goal.

Yes, because we don't have 101 keys to work with. Hence the need for compromise, take parts that people are familiar with, parts of a standard, parts that are necessary, parts that will work, discard things that can't be done, remove things that don't work, drop low priority things that conflict with higher priority things, something we have been over time and time again and I don't know why I keep trying to explain this to you when you just don't seem to get it.
Honestly I don't understand what you're argument even is here. In a single sentence what are you actually trying to say?

Are you saying "we don't have enough keys therefore we can't do punctuation pairs"? Because that doesn't make sense, lack of keys means all the more reason to double them up where we can, especially if we already have a standard base that people are familiar with.

Are you saying "US layout doesn't have an AltGr therefore we shouldn't depend on it"? Because that doesn't make sense either since all layouts will necessarily depend on it.

Just what are you trying to say?

 

[comradekingu]

Im saying too much of a good thing is overall worse.

Edit:

Im saying US layout doesnt have an AltGr (thirdlevelshift), so important aspects of what makes it US layout, are incompatible with the amount of keys we have at our disposal.

There are 15 things on the list.

You need 15 keys for that.

That means this if you dont fully utilize the numberrow, and the amount of standard keys you can implement if you do it differently.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

dot colon . :   and   comma semicolon , ;  is another, more logical comparativly standard way to do one of the pairs than ,< and .> , so some of the time its a question of more than userbase alone.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Thirdlevelshift isnt the same for everyone if you move some of the symbols over to the letters.

Because those keys also have similar functionality for other compose and dead-key functionality, and for symbols, and letters, depending on what is implied based on region of the users layout, which the user expects.

Doing it one way, even visible to all being some sort of a bonus, is incompatible with all the others.

 

[_wb_]

There are 15 things on the list.

You need 15 keys for that.

Are you talking about that list of diacritics?

Not all of those are equally important.

Acute, grave, diaeresis/umlaut and circumflex are clearly the most important ones for Western European languages.

Tilde is important for Portuguese (including Brazil).

Cedilla and ogonek are similar, and both use Compose comma <letter>, which works since there is no overlap between the sets of letters you apply them to.

Caron and dot are important for several Eastern European languages.

Those 8 (or 9 if you distinguish cedilla and ogonek) are the most important ones.

The other diacritics are either used in only one language, or on only one letter:

• Ring above is mostly used for the Scandinavian å, but if you need that letter, you probably don't want to use the dead diacritic method to get it (you would map it as a direct key).
• Slash is only used for the Polish Ł and the Scandinavian Ø -- again, you'll want to map it as a direct key instead of using the dead diacritic method.
• Double acute is only used in Hungarian.
• Breve can be grouped with caron because it looks similar and there is no overlap between the sets of letters.
• Macron is not actually used in any language, it is mostly used in transcriptions of non-Latin languages.
• Line through (đŧħ) is only used in Vietnamese and Northern Sami as far as I know

 

[MrConfusion]

(

Sidenote:

Saying "US keyboard does not have AltGr" is kinda like saying "These things go to eleven". There's left ALT and right ALT and whether you label the scancode for right ALT "AltGr" or just "ALT" makes very little difference... true, many laptops omit right ALT completely, because it is pretty much only used in old CGA Pong games within the US .

In such laptops it is often "stuffed there" in international keyboards. But international keyboards tended to be 102-key ones... So one key more than US and that key typically resides next to left shift it is not AltGr. Of course in Japan and other eastern countries there are even more real scancode additions. I know nothing of them and whether or how they overlap.

Also don't forget, thanks to Windows the modern desktop keyboard standard is actually 104 keys now (intl is then 105 keys). Yeah I'm saying just to make you tear your hair in frustration. This is assuming Windows95 on Pyra version of qemu becomes reality :-D.

)

 

[WizardStan]

Im saying US layout doesnt have an AltGr (thirdlevelshift), so important aspects of what makes it US layout, are incompatible with the amount of keys we have at our disposal.

Yeah, you're still not making any sense at all.It sounds like you're saying "since we can't have a perfect 1:1 mapping we shouldn't even attempt it". If that isn't what you're saying then what relevance does a US layout not having a third level shift have to do with anything? Or are you still hung up on calling the Pyra's NECESSARY modifier AltGr vs fn or meta or whatever?

 

[MrConfusion]

One concrete suggestion: do NOT use RightAlt (AltGr) scancode for Pyra's modifier (Fn-like). That will probably make porting slightly trickier in many cases. Reason being AltGr combos are definitely bound to known symbols in several locales even though in US layout they do nothing. The person porting might have no idea this is the case. Rebinding the combinations to Pyra specifics is probably not where I would want to go if I were working at this problem.

For example, any of the FN13+ codes should do the trick for a scancode (will require quite a loadkeys script, but then again so did the Pandora layout). Not sure of console side, would need to try that out. But you can definitely just map that Fsomething to Mod3 or whatever for X. In X you don't need to follow any straight existing conventions, it sandboxes those away quite nicely. Actually any scancode reserved for exotic purposes, like multimedia keys, seem like prime candidates to me.

 

[WizardStan]

do NOT use RightAlt (AltGr) scancode for Pyra's modifier (Fn-like).

The only person who is even remotely suggesting the Pyra's Fn-like modifier be literally AltGr is comradekingu (because "that's what AltGr is for" as is my understanding), everyone else seems to have come to terms with it not being a good idea to have it be AltGr and in fact by making sure it is completely distinct we then have a situation where the user can then turn one of the Alt buttons into a real AltGr and use their languages native mappings.I don't think it really matters at the moment what keycode is used, as long as we agree on how it behaves the driver should be able to take care of the rest, either at the scancode or keycode level: important discussion to be had but not really relevant to how the keys are to be laid out.

 

[comradekingu]

Can you refrain from posting what you think im saying if you dont understand the argument?

The pyra doesnt have an "FN-like modifier" because the decision to include one, hasnt been made. Thats an apriori argument.

The premise of not being able to type your mappings by default is only backed up by the ad populace argument you constructed.

If you look here, you will see its important to 8% of the voters. Mixing Fkeys with AltGr is inherently less functional, and less standard.

Question, what do you think happens when you turn one of your alts into AltGr? You lose it. There was no redundant alt on either keyboard or shoulders to shed.

Its worse because then you have to be troubled to implement it. And its confusing because you then have two sets of doing the same thing.

You still have the letters full of symbols, or dedicated keys removed from their positions, take your pick.

---------------------------------------------------------------------------------------

Wb: I never said they were equally important. Hence the attention to positioning.

What i said was i think they are an important aspect of US layout, making it more than something a group of users have a vested interest in.

 

[WizardStan]

Can you refrain from posting what you think im saying if you dont understand the argument?

No. Eventually I'm going to accidentally stumble upon what you are trying to say and everything will make sense, we'll be able to move forward and figure out the best course of action, but until then I'm just going to have to keep guessing.

 

[comradekingu]

Consider this.  

Having AltGr means you have AltGr, there is no alternative to it that does the same in the same manner. Ctrl+alt does R_alt in the same manner as US international, because its an alternative way of doing it. There is no such alternative to having Alt and AltGr keyboard, and Alt and AltGr shoulders.

You have every bit of functionality lumping thirdlevelshift and pressing F-keys together have, with none of the problems it causes. If you also have a mod key to type F-keys with, you have reinstated everything except pressing F-keys with shoulders.

You dont lose/inconvenience that 8%, because option A is compatible with option B, but option B is incompatible with 8%

Same as with the the keys to the right of P and L, dedicated keys in dedicated positions isnt optional. Unless you think selling a keyboard to an englishman that is missing vowels is a alluring business-prospect.

Functionally its an option that is more compatible with english typing key-positions, and more importantly it allows a lot of people who arent using an A-Z alphabet to type.

So you dont lose/inconvenience half the audience.

If you go for A-Z only, you are only compatible with A-Z. Whereas the other is compatible with A-Z++++ and features as many of the additional keys found on A-Z keyboards as possible.

 

[Grench]

My position/reasoning about the DosBox / US-QWERTY symbol pairs is as follows:

1. The software issues with DosBox are just software issues and can be solved.

 The 'issue' with DosBox occurs over many platforms and has 'been that way' for years. It hasn't been 'fixed' yet on any platform. This is not a simple software key-remapping problem, but has to do with the fundamental way that DosBox interacts with a keyboard as a hardware device. Many very smart people have looked into it and so far the 'best' solution is to carry around a reference sheet of which symbols work, don't work and which ones have to be produced without mapped symbols.

This issue is NOT just with DosBox. It is ANY software that addresses the keyboard as a physical array of hardware keys. DosBox is simply the easiest to point to example.

2. Still, I think it makes sense to let the Pyra keyboard resemble one standard as closely as possible. US-QWERTY is a natural standard.

 Agreed.

Facts:

• This CAN be done.
• The Pyra does not have enough keys to 'do it' without using a hardwaresque Fn key.
• To do it, we have to decide whether the symbols `-=[]\;',./ or the numbers 1234567890 and by default their shifted pairs are going to be relegated to the Fn layer. It is either or, not both.
  

3. Shift+Meta is certainly possible (we want Shift-F-keys for example), but it is slightly less convenient than just one modifier.

 Shift+Meta/Fn is not only possible, it MUST exist and WILL be a common action. By now we should all understand and acknowledge this fact.

Shift+Meta/Fn does not have to be less convenient than just one modifier. Shift+Meta/Fn CAN be placed next to each other (on both the keyboard and the shoulder) to result in a chorded modifier. It is one press covering two buttons. There does not need to be any physical action difference between Fn+key, Shift+key and Fn+Shift+key.

4. Because of point 3, I prefer to have {}|:"?_+~<>!@#$%^&*() behind only one modifier (Shift if the unshifted key is available as a dedicated key, Meta otherwise), but because of point 2, I want the shifted symbols near the unshifted symbols so they still form pairs in a systematic way.

 Your preference requires breaking your statement in #2 above. If you break those symbol pairs you no longer have anything remotely resembling a US standard keyboard layout. That is a substantial loss in usability and compatibility.

It doesn't gain much at all. As stated above in #3, the difference in user actions is negligible between Fn+key, shift+key and Shift+Fn+key IFF the layout is set up for chord modifiers.

So, big loss, little to no gain.

5. Duplicating the labels for the shifted symbols looks ugly and weird, and it feels wrong. There is nothing wrong with making Shift+/;'[]`-= produce the corresponding shifted symbols by default though.

 Agreed - duplicating the symbols is ugly and weird.

There are TWO somethings SUBSTANTIALLY wrong with making shift+`-=[]\;',./ produce the corresponding UNMARKED shifted symbols. It confuses from TWO directions. First, unless the end user has fully memorized all of the symbol pairs from a US keyboard, they won't know WHICH symbol's shift produces the character they want. Second, pressing keys labeled as ~_+{}|:"<>? will produce unpredictable results or nothing, which will result in confusion and frustration.

It makes MUCH more sense to NOT break the standard US layout by splitting the symbol pairs of shifted and unshifted keys. It would be the same as rearranging !@#$%^&*() instead of putting them on 1234567890. Symbol pairs SHOULD be maintained, and not just for DosBox but for general usability and compatibility.

I made yet another layout proposal in this spirit:

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

(it's called "_wb_ diacritics" in the big comparison table)

The idea is that all symbols which did not get a dedicated key are on the Meta+ASDF row, and the corresponding shifted symbol is diagonally on top in the Meta+QWER row.

Sorry, but the only parts of that with any resemblance to a US standard keyboard are the letters and numbers. I see what you were trying to do - putting the shifted version of the key above the unshifted but both on Fn, but it simply results in a seemingly random mess.
I find this to be MUCH easier to understand and find keys on, but then I'm biased towards it:

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

The big thing to emphasize, though, is that we can have symbol pairs on the top layer or numbers on the top layer, but one set or the other must be on the Fn layer. If we want to keep the number of symbols down to 3, then it needs to be the number keys that go to the Fn layer.

 

[comradekingu]

Lets see, what do i have least use for, real keys or real numbers. Could it be that broken software is what i have the least use for?

You need both numbers and brackets for coding, and coding is easily less marginal than broken software.

You dont need brackets for language, so you can do without them then, and reinstate them in a more advanced way for those advanced people.

The problem here isnt that you set out to solve broken software, the problem is you arent considering the decisions you forego in doing so.

Language, games, coding, in that order. Trading language for half the people and coding seems like an unfair trade for broken games.

Edit: So what would i do if i wanted to play a dos game that required all characters. I would plug in a keyboard.

This would require me to be at home, but ok, lets consider the option.  The option is not being able to type non-english, on the go, which is what the use-case and the userbase wants to do.

The real answer is hacking hacky software back into shape, you only need at worst one level of arbitration to do it.

Or making a keymat for all the broken-software-loving english people.

 

[codifies]

This issue is NOT just with DosBox. It is ANY software that addresses the keyboard as a physical array of hardware keys. DosBox is simply the easiest to point to example.

You cannot expect to do it with a simple keymap to keymap lookup table... Instead you need to monitor Key up/down events and then translate these events into a set of events that would happen if you were using a "real" US keyboard.

For example the user on some custom keyboard does some vulcan nerve pinch combination of key presses, the keyboard translation layer recognised this 3 key combo (giving time to ensure the first two key down keys aren't the actual key - the user might press shift then P then altGr the altGr might land a few milliseconds late) The translation layer would then send for example alt and N (or whatever) keys down events that a "real" keyboard would generate, to the application...

The reason its not been implemented is probably because no one who can, could be bothered to waste anymore time on it that just a simple keymap to keymap lookup table...

This is one reason (of many reasons) why you should NEVER use low level hardware values for things like keys (or anything else)

Its a pita yes but eminently possible - and certainly no reason to hobble a keyboard at a hardware level.

 

[szr]

My position/reasoning about the DosBox / US-QWERTY symbol pairs is as follows:

1. The software issues with DosBox are just software issues and can be solved.

2. Still, I think it makes sense to let the Pyra keyboard resemble one standard as closely as possible. US-QWERTY is a natural standard.

3. Shift+Meta is certainly possible (we want Shift-F-keys for example), but it is slightly less convenient than just one modifier.

4. Because of point 3, I prefer to have {}|:"?_+~<>!@#$%^&*() behind only one modifier (Shift if the unshifted key is available as a dedicated key, Meta otherwise), but because of point 2, I want the shifted symbols near the unshifted symbols so they still form pairs in a systematic way.

5. Duplicating the labels for the shifted symbols looks ugly and weird, and it feels wrong. There is nothing wrong with making Shift+/;'[]`-= produce the corresponding shifted symbols by default though.

I made yet another layout proposal in this spirit:

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

I just have a couple small questions about this layout.

1) Where you say "Shift+Shift: Caps Lock", would this invoke the real Caps-Lock key that exists on most full-size keyboards as a distinct key (and whose behavior differs from simply holding down shift) or is it simply making shift sticky? I think the former would be better as there doesn't appear to be a a caps-lock anywhere else. Perhaps Shift+Shift = real Caps-Lock key, and perhaps Meta+Shift+Shift = sticky Shift? Or would the latter be too strenuous?

2) What exactly does "eta lock" mean, where you wrote "Meta+Meta: eta Lock" ?

3) I really like the idea of the lid closed acting as Super being held down, allowing for media controls as mentioned in the layout. My only question is, would this cause the battery to drain quicker, as it would be like holding a key down for a long time. I'm not sure if that uses any more power than with no keys being held, or if the extra usage would simply be very negligible.

4) This is a very small thing. I noticed that you have PrtScn and SysRq as separate keys, and I wonder if that really is needed. On most keyboards that I've seen, the latter is the Shift (or is it Ctrl?) + the former. Maybe have the key labeled SysRq be Pause/Break instead, and maybe meta + that key be Scroll Lock?

Also, is SysRq actually used by something? I've noticed many layouts posted seem to put it in such upfront positions, so maybe there is something I don't know about regarding it.

Thanks.

 

[WizardStan]

You have every bit of functionality lumping thirdlevelshift and pressing F-keys together have

There. Right there. That thing that you just said, the functionality that you are describing in that exact sentence is precisely what everyone else is referring to as "fn-like" (or whatever their exact words are, everyone else understands what we're all talking about when we say whatever it is that is said, except for you)

with none of the problems it causes.

Except that there ARE problems. The problems have been explained to you at length but I will summarize, once again, the two that I feel best represent the difficulty (I had a third one but as soon as I started typing I forgot what it was. It'll come back to me eventually.)1) You are using a key that a lot of people are familiar with in a way that they are unfamiliar with. This has the potential to cause confusion. This is distinctly different from doing things in a non-standard way out of necessity, or inventing a new standard where one never existed before: this is something that already exists, and you are intentionally doing it differently.

2) It is strictly limiting: by having a specific AltGr key you are stripping away the users ability to use a keymap that relies on a REAL AltGr (that is, treat R_ALT as a soft mod) without causing confusion.

Both of these problems (and in fact all problems that you're failing to address with it) completely disappear if you simply call it anything other than AltGr. Seriously. That's it, that's all you need to do. Stop calling it AltGr: call it Fn; call it Meta; call it Sym; call it quijibo for all anyone cares; just stop pretending that it is analogous to AltGr, because it isn't and it's extremely disingenuous the way you try and convince people that it is.

You literally gain nothing by insisting that it is AltGr vs ANY OTHER NAME, and lose a lot through potential confusion. Seriously, to quote you on the subject of doing things in non-standard ways, "who does that?"

 

[Grench]

This issue is NOT just with DosBox. It is ANY software that addresses the keyboard as a physical array of hardware keys. DosBox is simply the easiest to point to example.

 You cannot expect to do it with a simple keymap to keymap lookup table... Instead you need to monitor Key up/down events and then translate these events into a set of events that would happen if you were using a "real" US keyboard.

For example the user on some custom keyboard does some vulcan nerve pinch combination of key presses, the keyboard translation layer recognised this 3 key combo (giving time to ensure the first two key down keys aren't the actual key - the user might press shift then P then altGr the altGr might land a few milliseconds late) The translation layer would then send for example alt and N (or whatever) keys down events that a "real" keyboard would generate, to the application...

The reason its not been implemented is probably because no one who can, could be bothered to waste anymore time on it that just a simple keymap to keymap lookup table...

This is one reason (of many reasons) why you should NEVER use low level hardware values for things like keys (or anything else)

Its a pita yes but eminently possible - and certainly no reason to hobble a keyboard at a hardware level.

Which is exactly why we need to maintain the US standard keyboard character and symbol pairs. So the keyboard works -properly- at a hardware level, regardless of the application used on it. We cannot 'hobble' it by arbitrarily breaking these pairs to randomly salt them over the layout.

 

[_jr_]

I was under the impression that the so called dosbox compatibility issue simply cannot be solved in dosbox alone (unless you want to introduce additional latency). AFAIK at least for some applications it is neccessary to have the shift down happen before the actual key press.