It's the keyboard layout.


Last edited by a moderator:
Ok, as I've been asked to participate, here goes:


@ED:


I have no idea what layout is going to work for me, all I know is I would like some of the irritations of the Pandora keyboard resolved... I.e I want full dosbox compatibility and all the other benefits that would bring. I also really like the idea of compose, so would like to be able to do that with the Pyra, regardless of what characters end up on the keys.


Oh, and I think that full stop and comma should be dedicated, but I don't mind if things like exclamation and question mark are on modifiers.


Right, I have now contributed. ;)
 
I added yet another proposal (sorry about the lots of proposals, I have five now in the big table), this time with a left-aligned QWERTY row and a single-width space.

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

What I love about such a layout is that you can get a lot of punctuation keys (comma dot slash apostrophe) close to their expected location, and also you could remap this to dvorak or any language-specific layout that uses P+2 L+2 M+3.

The only real disadvantage I see is that the number row and the QWERTY row are no longer aligned.

This new one is "_wb_ 4" in the table, yesterday's centered single-width-space is at "_wb_ 5".

https://docs.google.com/spreadsheets/d/14mVNNzLhmhyA4sCIAPSoDv404xtctfLSiEMTtTlEzfw/edit#gid=1574311258

I only add these proposals because I'm still not sure if the double-width space is really a final decision or just a strong preference. If it is a final decision / hard constraint, feel free to ignore this stuff.

If the space is going to be double-width, please make sure that it is not too wobbly/flimsy. The Pandora space key is already a bit on the edge, and since the Pyra keys will not be square but rectangular, I fear that a double-width space key will be very wobbly.
 
FaeMinx said:
Ok, as I've been asked to participate, here goes:

@ED:

I have no idea what layout is going to work for me, all I know is I would like some of the irritations of the Pandora keyboard resolved... I.e I want full dosbox compatibility and all the other benefits that would bring. I also really like the idea of compose, so would like to be able to do that with the Pyra, regardless of what characters end up on the keys.

Oh, and I think that full stop and comma should be dedicated, but I don't mind if things like exclamation and question mark are on modifiers.

Right, I have now contributed. ;)
Click to expand...
If you require DosBox compatibility, I have two options for you. Which would you prefer? Numbers on top or symbols on top?
Numbers on top and symbols on Fn:

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

Symbols on top and numbers on Fn (now with more explicit non-English symbols added to Fn):

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

This updated version has not been added to the keyboard matrix yet. I simply don't have time at a large screen right now. _wb_ is welcome to update the existing Grench new entry if he has the time.

In both instances the 'not on top' numbers or symbols can be easily accessed with the Fn+key method. Both of these should make DosBox and QEMU happy as all of the traditional US keyboard symbol pairs are retained. Each has obvious advantages and disadvantages.

There are a few 'hidden' advantages to each though.

With the numbers on top, all of the symbol keys (`[]\;',./) wind up being at or very close to their original positions, just behind the Fn layer.

With the numbers behind the Fn layer, all of the symbol pairs are 'right there' AND it frees up a lot of the international mappings.

In both of these instances, diacritic dead keys and direct support for English, German, French and Spanish are available. Both are also able to activate the right Alt key (on the keyboard) as an AltGr.

WizardStan has a layout that comes somewhere in between my two listed here.

The majority of the rest will not readily meet your DosBox needs (not clearly marked for DosBox OR no DosBox key pairs.)

I'm interested in your thoughts.

Thank you.
 
Last edited by a moderator:
I don't really understand this "DosBox compatibility" thing. There are plenty of non-US keyboards, I cannot imagine that DosBox does not work on them.
 
  • Like
Reactions: szr
_wb_ said:
I don't really understand this "DosBox compatibility" thing. There are plenty of non-US keyboards, I cannot imagine that DosBox does not work on them.
Click to expand...
It's been an annoyance for me ever since I got my Pandora and wanted to mess around with old DOS games on it. Master of Magic works great on the Pandora BTW - at least until you need to left-click with the stylus.

The way I understand it, DosBox is monitoring keystrokes at a lower level. I.e. it doesn't see the | character, but instead sees shift is being held and the \ button was pressed then produces the | character, regardless of what is printed on the keyboard.

So, if you have { mapped to a key (or Fn level key) and press it, you get nothing. If you have [ mapped to a key and press shift + [, you get {.

So, if your keyboard breaks the symbol pairs, DosBox and QEMU end users are hunting around trying to figure out what the paired mapping 'should have been' in order to generate a symbol. This was an annoyance on the Pandora that does not need to be repeated.

For example, open DosBox on your Pandora and try to type in the commands:

dir *.* /s >filelist.txt

type filelist.txt |more

Not having the right symbols on the right keys results in frustration. They cannot be 'easily remapped' at the PND/application layer due to the, maybe weird/wrong/whatever method, that DosBox and QEMU uses to interpret keyboard commands.

At least that is my understanding of the issue. Pickle or one of the other DosBox/QEUMU gurus could likely provide a more technical and correct answer, but they also may not be lurking on these conversations.

Edit:

Oh, and it appears that QEMU uses the same weird keyboard methodology that DosBox uses, which means that this persists when trying to run X86 linux applications using the ExaGear system - which is a big thing for the Pyra.
 
Last edited by a moderator:
Last edited by a moderator:
I don't have time to look at anything today. Arrived home from a 4 day festival, 6 days away from home... to find my mother had unplugged the ice cream freezer when packing one of the multiplugs... and our entire stock we had built up for while she's oversees for the next 5 weeks had melted.


So.


...


I will be busy today.





...


But I don't mind if numbers are on the fn layer, with dedicated symbols... I think such easy access would be fantastic. As long as fn is sticky.
 
Last edited by a moderator:
Grench said:
_wb_ said:
I don't really understand this "DosBox compatibility" thing. There are plenty of non-US keyboards, I cannot imagine that DosBox does not work on them.
Click to expand...
It's been an annoyance for me ever since I got my Pandora and wanted to mess around with old DOS games on it. Master of Magic works great on the Pandora BTW - at least until you need to left-click with the stylus.


The way I understand it, DosBox is monitoring keystrokes at a lower level. I.e. it doesn't see the | character, but instead sees shift is being held and the \ button was pressed then produces the | character, regardless of what is printed on the keyboard.


So, if you have { mapped to a key (or Fn level key) and press it, you get nothing. If you have [ mapped to a key and press shift + [, you get {.


So, if your keyboard breaks the symbol pairs, DosBox and QEMU end users are hunting around trying to figure out what the paired mapping 'should have been' in order to generate a symbol. This was an annoyance on the Pandora that does not need to be repeated.


For example, open DosBox on your Pandora and try to type in the commands:


dir *.* /s >filelist.txt


type filelist.txt |more


Not having the right symbols on the right keys results in frustration. They cannot be 'easily remapped' at the PND/application layer due to the, maybe weird/wrong/whatever method, that DosBox and QEMU uses to interpret keyboard commands.


At least that is my understanding of the issue. Pickle or one of the other DosBox/QEUMU gurus could likely provide a more technical and correct answer, but they also may not be lurking on these conversations.


Edit:


Oh, and it appears that QEMU uses the same weird keyboard methodology that DosBox uses, which means that this persists when trying to run X86 linux applications using the ExaGear system - which is a big thing for the Pyra.
Click to expand...
I don't see why this should be a fundamental problem and not just a matter of configuration. If DosBox can be made to behave correctly for someone with, say, an AZERTY keyboard, then why not for someone with a Pandora or Pyra keyboard?
 
_wb_ said:
I don't see why this should be a fundamental problem and not just a matter of configuration. If DosBox can be made to behave correctly for someone with, say, an AZERTY keyboard, then why not for someone with a Pandora or Pyra keyboard?
Click to expand...
It seems to be designed around the assumption that the physical keyboard has the normal number of keys, and mapping is on a per key basis, not a per symbol basis,   so hiding regular punctuation symbols behind a 3rd level modifier is beyond the design scope of it's keyboard mapping tool.  I don't know,  but I suspect it would deal with AZERTY by loading the DOS code page for an AZERTY keyboard layout.  There was never a DOS code page for the Pyra keyboard though.  (funny that)

- Neelix
 
Neelix said:
_wb_ said:
I don't see why this should be a fundamental problem and not just a matter of configuration. If DosBox can be made to behave correctly for someone with, say, an AZERTY keyboard, then why not for someone with a Pandora or Pyra keyboard?
Click to expand...
It seems to be designed around the assumption that the physical keyboard has the normal number of keys, and mapping is on a per key basis, not a per symbol basis,   so hiding regular punctuation symbols behind a 3rd level modifier is beyond the design scope of it's keyboard mapping tool.  I don't know,  but I suspect it would deal with AZERTY by loading the DOS code page for an AZERTY keyboard layout.  There was never a DOS code page for the Pyra keyboard though.  (funny that)

- Neelix
Click to expand...
So does this also mean that DosBox can only work correctly if we have a hardware Fn modifier then?
 
I don't think we should be complaining too much about the weights that certain voters put on any property.  That's their vote, and we fix things to make each user get a normal(ized) vote.

The best thing to do, if you think someone is outlandishly specifying their weights, is to design a keyboard which beats their own keyboard at their weights.
 
Last edited by a moderator:
ible said:
I don't think we should be complaining too much about the weights that certain voters put on any property.  That's their vote, and we fix things to make each user get a normal(ized) vote.

The best thing to do, if you think someone is outlandishly specifying their weights, is to design a keyboard which beats their own keyboard at their weights.
Click to expand...
Its so over complex you're almost certainly not voting like you think you are - these things are near impossible to get right and even then of dubious validity
 
You must log in or register to reply here.

Similar threads

EvilDragon
Current Keyboard Layout
19 20 21
Replies
413
Views
50K
Xcl4m4t10n
Xcl4m4t10n
Pyramancer
Two keyboard layout questions
Replies
10
Views
5K
levi
levi
comradekingu
  • Poll
Testing alternative Layouts that require single-width space. INTL layout vs Big Space, and other key
14 15 16
Replies
305
Views
47K
benoitb
benoitb
_wb_
Final keyboard layout proposals
Replies
14
Views
12K
Grench
Grench
ible
Hoping for a keyboard vote
2
Replies
21
Views
3K
Grench
Grench
Back
Top