WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
As previously demonstrated it really is possible.
It's the keyboard layout.
- Thread starter Silent-Hunter
- Start date
MrConfusion
Very Active Member
- Joined
- Apr 11, 2013
- Messages
- 331
But user friendly also for those who wouldn't touch a legacy computer with a ten foot pole? Is it "logical" in their point of view? OK, wont argue further points made...
Two more aspects came to my mind:
The Majority, i.e. console gamers, are somewhat spoiled with choices in gaming devices: Android phones with or without extra controllers, Shield, Chinese junk, you name it...
In contrast, legacy computer people really have only one option at the sub-netbook level (ignoring eBay hunts for old palmtops...).
So from a business perspective the later guys are already won over and are a minority, the majority must be competed for... do the math... :-D. (And before anyone barks, I'm strictly in this minority, so "I got me rights to say so..." ;-)
Second matter: Like I've said in other threads, DOS specifically suffers from an even more pressing issue: Mousing. And this in many of the games that would have wider appeal in the eyes of people who "were not there back then". Pre mid 90s DOS games are not only difficult to control (as codifies said), but often impossible, typically exotic to navigate without having the manual.
And then those who have the manuals and all there's another issue: I hoped to use the Pandora for many games which I've since given up on and simply resumed playing in my HW DOS BOX (Pentium2, SBAWE32ISA,Roland LAPC-1 and most importantly: MOUSE --> its a very different experience imo...).
I say again: go after the crowds, solve minorities later with some hacknugly... like with the Pandora
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Yes.
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
(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.
This layout deviates quite a bit from my other proposals in that no longer has Meta+vowels available for language-specific letters like äüö. So that's a downside. On the other hand, it has a lot of dead key diacritics (indicated with ◌ ) so you can still input accented letters in only two thumb presses. Alternatively you can set R_Alt to AltGr and have a layer available for whatever special letters you need to have in just one thumb press.
I also 'freed' the 'special' keys Backspace, Enter and Tab from Meta-symbols. I think that looks cleaner. F11 and F12 were moved to Meta+ZX (they were on Meta+Backspace and Meta+Enter), which is perhaps a bit odd, but it also means that F11 (often used to toggle full-screen) becomes a mashable key.
This proposal does not include just the standard ASCII symbols, but also all of the special symbols found on a German keyboard: § ° µ ² ³ € ß (on a French keyboard, you also have § ° µ ² € by the way). I don't really need those symbols, but it's a nice little extra feature for Germans, I guess. Perhaps they rather like to have dedicated Ü Ö Ä keys though. In the proposal as it is now, they would need to use dead diacritics for that (just like any other language), in this case Meta+" to get the dead umlaut, followed by U O or A. Dead umlaut is presumably a mashable action, although that would have to be tested.
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
(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.
This layout deviates quite a bit from my other proposals in that no longer has Meta+vowels available for language-specific letters like äüö. So that's a downside. On the other hand, it has a lot of dead key diacritics (indicated with ◌ ) so you can still input accented letters in only two thumb presses. Alternatively you can set R_Alt to AltGr and have a layer available for whatever special letters you need to have in just one thumb press.
I also 'freed' the 'special' keys Backspace, Enter and Tab from Meta-symbols. I think that looks cleaner. F11 and F12 were moved to Meta+ZX (they were on Meta+Backspace and Meta+Enter), which is perhaps a bit odd, but it also means that F11 (often used to toggle full-screen) becomes a mashable key.
This proposal does not include just the standard ASCII symbols, but also all of the special symbols found on a German keyboard: § ° µ ² ³ € ß (on a French keyboard, you also have § ° µ ² € by the way). I don't really need those symbols, but it's a nice little extra feature for Germans, I guess. Perhaps they rather like to have dedicated Ü Ö Ä keys though. In the proposal as it is now, they would need to use dead diacritics for that (just like any other language), in this case Meta+" to get the dead umlaut, followed by U O or A. Dead umlaut is presumably a mashable action, although that would have to be tested.
comradekingu
Glowing ember
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.
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.
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
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
Glowing ember
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.
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.
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
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
Glowing ember
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.
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.
Last edited by a moderator:
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
Very Active Member
- Joined
- Apr 11, 2013
- Messages
- 331
(
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.
)
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
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
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
Very Active Member
- Joined
- Apr 11, 2013
- Messages
- 331
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.
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
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
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
Glowing ember
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.
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.
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
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
Glowing ember
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.
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.
Last edited by a moderator:
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
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.
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.
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.
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.
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.
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.
Last edited by a moderator:
comradekingu
Glowing ember
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.
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.
Last edited by a moderator:
codifies
Very Active Member
- Joined
- Sep 29, 2014
- Messages
- 360
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.
