It's the keyboard layout.


I understand the poorness of the standard. But to fight that we should probably head over to Colemak ;) . I do agree with the Home/End/PgUp/PgDn cross, but that's been part of the layouts for ages ;) .

It is true (with xev) that equals plus and numkey plus are two different keyboard signals. It's a strange world we live in.
 
Wouldn't having "compose" on a key combination that is also used as a standard modifier combination cause problems? (meta+shift)

- Neelix
 Not really. It would only be Compose if you press Meta+Shift and then release both of them. Compose is not a modifier but it's a key you press and release before combining two symbols, so there's no problem having it at Meta+Shift. The only thing is that you can't have sticky Meta and Shift and Compose at Meta+Shift.

Personally I would probably not use keyboard Shift and Meta at all, so I would probably use the keyboard Shift key as a dedicated Compose key.
I just set compose to right super + altgr on my work computer with
Code:
setxkbmap -option compose:rwin-altgr
Pressing rwin+altgr doesn't compose, altgr+rwin does compose. :D
 
attachicon.gif
nr64german.png
How does that space work?
It works as if it was two buttons. You get something that looks like space so you know where it is. And you get the benefit of this http://boards.openpandora.org/topic/16736-testing-alternative-layouts-that-require-single-width-space-intl-layout-vs-big-space-and-other-key-layout-decisions/#entry348154
 
Last edited by a moderator:
The most central position (being the left one) is space, the other one is . : /   (Implied here that a more central space is a more usable one, since thats where your right thumb is coming from, and less distance traveled, is better)

The usable space is akin to the same way the enter/return key isnt shaped in a traditional way. Because it isnt on a traditional 10-finger keyboard. Havent seen anyone complain about that on the pandora. Because the pandora, like the pyra, is a two-thumb keyboard. It is very possible to get this wrong. The ogo wastes key-estate on the enter-key. Note however that the wideness of the space has merit, because you can reach it with both hands. Each end is more central to each thumb than the middle would be, and also you can move straight down.

That way of doing it is good from getting to space from comma. Or dot to space. But they failed at getting from dot to enter. And they also lack the shift you need in between getting from dot to space.

Other than recognizability, there isnt a reason to make it a long-space if it is in a non-central position.

Now if we go into the details, lets see what actually happens. Looking at the PCB it isnt actually made to be pressed in the middle. Because there is no point of contact directly underneath it, like on a regular keyboard. 

To my knowledge, there arent any support-structure in place (like the stabilizers on an actual space_bar_  1  2  or keys that are more than 1-wide) to make sure the travel isnt the uneven wonkyness it is on the pandora. Make the key longer, like on the pyra, and you worsen the problem.

Membranes collapse unevenly if you happen to move the actuation away from the centre. There is no stem to fit in a slider.

Now if you press it the wrong way, it will bottom out on one side before the other. Try it on the pandora.

TL;DR if something is different from a space-bar, for how a space-bar makes sense, its the long key you find on a pandora.

Edit: Added some meat to the argument.
 
Last edited by a moderator:
I'm not super comfortable with the place of insert and delete on _wb_'s layout here.
Why?  When typing they are out of the way, so you won't hit them by accident, and when playing games they should be mapped to game controls.  If you think they are too far away, many people are concerned about delete being destructive.
How often do you hit Home or PageDown by accident on the Pandora?  I suspect that will be about the frequency in which you accidentally hit delete when typing, if it is the lower small face button.  As other people have noted, it's nice to have Ins and Del near to Home/End/PgDn/PgUp, since that is a standard grouping.

Also, ins and del can be remapped in games.  Pressing Ins in a game won't put your computer into Insert mode until the next time you hit it for all other programs.  AFAICT, Ins only puts a linux program into "insert mode" if the program has an insert mode, and then only if Ins was hit when the program had focus.

That was initially one of my concerns with having Ins and Del near PgUp, etc., but then I realized how Linux programs worked ;) .
For some reason I thought he had them on + and -.  We are in agreement.

Edit:

What actions do the nautical symbol and the scuba guy(octopus symbol) keys fulfill?
Maybe they are "Controll" and "Run away".
 
Last edited by a moderator:
Here is another, more 'Grenchified' version of my proposal:

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

In this proposal, all of the punctuation symbol keys are available, more or less near their normal position, as a Meta-key. The shifted Meta symbols are completely standard. There are seven such keys: `~    -_    =+   [{   ]}    \|    ;:    and   /?. The other three punction keys are dedicated primary (non-Meta) keys: ,<   .>  and '".

Most of these Meta keys are at the right hand side, which should help for those who use the keyboard modifiers only.

A nice thing is that [ ] and { } end up neatly below ( ), which makes plenty of sense.

There's no more room for ₤ or Ł at L, and obviously some symbols have been 'demoted' from being a direct Meta-key to being a Shift-Meta-key, but I think it's conceptually nice to get this close to a standard US-QWERTY keyboard. Also æsthetically it is pretty nice to have most of the letter keys free of clutter. Of course we could add labels for the default Meta-mapping of those letters (e.g. ÄÇ€ÑÖÜߥ and so on), but I wouldn't do that. The latin letter by itself can serve as a mnemonic, it doesn't help to have an extra label Ä if you're going to want to map it to À or Å, to the contrary.
This one is very promising.  I like that DosBox and QEMU should work with it.  Although not exactly as I would do it (I'm fond of having the shoulder modifier buttons mirrored in the corners of the keyboard instead of on the center buttons), I could live with this.  

This meets my criteria.

DosBox friendly

Possible to use it in a dock or on a desk without the shoulder buttons accessible.

I like how it deals with the international needs.

It's a pretty 'clean' layout.

I'm still inclined to map Ins and Del to the 5th and 6th gamepad buttons to keep them with the Home/End/PgUp/PgDn set, but I can also see where having the + and - keys out where they're easier to use for zoom in/out.  With your idea of having a 'pop up overlay' with system controls, I could see these in conjunction with the navigation buttons being a quick way to adjust system settings.

How would you feel about Meta++ = volume up and Meta+- = volume down, Meta+End = next track, Meta+Home = last track, Meta+PgUp = Play/pause, Meta+PgDn = record?  They would not need to be printed on the keyboard, but if Meta+ the game buttons returned a different code than the unmodified version, they could be mapped to media playback or other - which would include the potential to map them to translate directly to their un-Meta functions if someone decides that is annoying.

That brings me to an idea.  In a Meta+Shift possible world, every physical key has potentially 4 mappings.  I'm of the opinion that these should -all- be mapped to -something- so that they return a unique code.  That is that there would be unique codes input for 'Normal/unmodified', 'shifted', 'Meta', 'Meta+Shift'.  Any code will do even if it's just the ASCII box-draw mappings or whatever.  Don't panic.  These would -not- be printed on the layout.  The idea is to have it generate a code - that can then be translated or re-mapped to whatever function the end user wants it to do.  They could even be default mapped to translate to the un-meta version of the key.

This would lead to two keyboard layouts, one printed with the presented symbols and one with all of the actual code results from each of the 4 potential code results from each key.

Any thoughts?
 
(was busy explaining the argument presented above)

Well, the running man that looks a bit like the alt symbol is the combined  Start/Alt

The helm (iso-symbol for ctrl) with a selection in it, is the combined             Select/Ctrl

I dont pretend this is good, but its what i thought i could improve on, after i couldnt improve the actual layout, and because i think its pretty broken on the pandora.  

SELECT/CTRL on one small key is less visual than the 3-symbols per key paradgimn run elsewhere.

At best i think its an ok way of remembering what they are, after you are notified of the fact. The fallback to doing it pandora-wrong remains.

Earlier i had it as two symbols on each key. But as design goes, removing without taking away. Cant win without trying. Cant fail without giving up.
 
Last edited by a moderator:
I understand the poorness of the standard. But to fight that we should probably head over to Colemak ;) . I do agree with the Home/End/PgUp/PgDn cross, but that's been part of the layouts for ages ;) .


It is true (with xev) that equals plus and numkey plus are two different keyboard signals. It's a strange world we live in.
Actually Dvorak and Colemak, for some reason, don't change the -_=+ insanity. They still have minus as a primary key and plus at Shift+equals.

Anyway, as I said before, I don't really have a very strong preference for Ins/Del or +/- on the extra action buttons. I can live with either option. According to my personal taste however, +/- is a slightly better idea than Ins/Del, but I won't repeat my reasons. And even in my most recent 'Grenchified' proposal, which does have Meta-keys for -_=+ in the insane standard way, it is still possible to also have +/- at the extra action buttons, because numkey plus/minus are still available as keycodes.

If you don't mind the potential issue with having Meta functions for action buttons, you could then even put numkey × ÷ (* /) at Meta + -. That kind of makes sense, arithmetically, and it would be nice for writing arithmetic expressions.
 
Last edited by a moderator:
I imagine thats because they think of it as a dash, not a minus.   I think both should be primary, or both secondary. I have a preference for Ins/del on the <^v>+2's  because then they are close to the cluster they belong in.

+ -  doesnt signify insert delete all that well.  If its zoom or something like that, you have the conflict where someone looks for + and presses + in the belief it will be +.

If it is actually + and - i think its worse than secondary  + and -   because you use - on a regular basis when typing.  Having to reach up to _not in the keyboard area_ is wonky.

Also i think the - symbol is useful in games, whereas losing insert and delete doesnt matter.
 
Last edited by a moderator:
I understand the poorness of the standard. But to fight that we should probably head over to Colemak ;) . I do agree with the Home/End/PgUp/PgDn cross, but that's been part of the layouts for ages ;) .


It is true (with xev) that equals plus and numkey plus are two different keyboard signals. It's a strange world we live in.
Actually Dvorak and Colemak, for some reason, don't change the -_=+ insanity. They still have minus as a primary key and plus at Shift+equals.

Anyway, as I said before, I don't really have a very strong preference for Ins/Del or +/- on the extra action buttons. I can live with either option. According to my personal taste however, +/- is a slightly better idea than Ins/Del, but I won't repeat my reasons. And even in my most recent 'Grenchified' proposal, which does have Meta-keys for -_=+ in the insane standard way, it is still possible to also have +/- at the extra action buttons, because numkey plus/minus are still available as keycodes.

If you don't mind the potential issue with having Meta functions for action buttons, you could then even put numkey × ÷ (* /) at Meta + -. That kind of makes sense, arithmetically, and it would be nice for writing arithmetic expressions.
I may have found an issue in this one and how it deals with dead keys.  It may be easy to fix.

' and " may not be the only keys needed...  What about ` and ~?  Since they're mapped on a meta-key, you can't Meta+~ and have it trigger diacritic mode or sacrifice ~ as a symbol itself...  I'm not sure what the fix is.  A possible swap is to move `~ to the top level with -_ on it's Meta level and tab to the space bar, but that lacks refinement.  Hmm...  I'm not the expert on language mapping though.
 
Last edited by a moderator:
Grench: The fix for that is having  ctrl+alt be diactric mode, as per US-international alternative to US-international AltGr functionality.

_wb_: How do you type French on it? Potential follow-up question would be, (unless im missing something), why is that so different from typing French on a French keyboard?
 
Last edited by a moderator:
Tilde is mostly needed just for ñ, so you can just use Meta-N for that one, instead of dead tilde. Grave could be dead by default (since backtick is so rarely needed), or you could map à and è at Meta-A/E.


To type French: map àèùçœ to Meta+AEUCO, use dead acute for é (or map it at Meta+W or Meta+R), map dead circumflex somewhere (e.g. Meta+Z) or use Compose, or map precomposed âêô at nearby locations (Meta-SRP or something).


Alternatively, remap everything to AZERTY and type blindly.


It is bound to be different from typing on a French keyboard because it's QWERTY and not AZERTY.
 
Actually Dvorak and Colemak, for some reason, don't change the -_=+ insanity. They still have minus as a primary key and plus at Shift+equals.
Minus (-) is used in text too so it's more used than plus (+). In the Dvorak minding, more used mean more accessible :)
EDIT:

It is bound to be different from typing on a French keyboard because it's QWERTY and not AZERTY.
There are French keyboards that are qwerty too like the one I'm currently using (Canadian French :p )
 
Last edited by a moderator:
Tilde is mostly needed just for ñ, so you can just use Meta-N for that one, instead of dead tilde. Grave could be dead by default (since backtick is so rarely needed), or you could map à and è at Meta-A/E.


To type French: map àèùçœ to Meta+AEUCO, use dead acute for é (or map it at Meta+W or Meta+R), map dead circumflex somewhere (e.g. Meta+Z) or use Compose, or map precomposed âêô at nearby locations (Meta-SRP or something).


Alternatively, remap everything to AZERTY and type blindly.


It is bound to be different from typing on a French keyboard because it's QWERTY and not AZERTY.
Sounds like you have that covered then.  Thank you for the response.

How do you feel about the idea that every (or nearly every) normal, shift+normal, Meta, Meta+Shift action should generate a unique code/symbol back to the OS (even if it is not printed)?  I suspect that this is more or less a requirement for your most recent layout and it's capability of re-mapping for language support.
 
It will be automatically the case that every key has 32 possible uses, one for every subset of {Shift, Alt, Ctrl, Meta, Super}. You can map anything to anything.
 
Mapping stuff isnt how you type a language.

Tilde is mostly needed just for ñ, so you can just use Meta-N for that one, instead of dead tilde. Grave could be dead by default (since backtick is so rarely needed), or you could map à and è at Meta-A/E.

To type French: map àèùçœ to Meta+AEUCO, use dead acute for é (or map it at Meta+W or Meta+R), map dead circumflex somewhere (e.g. Meta+Z) or use Compose, or map precomposed âêô at nearby locations (Meta-SRP or something).

Alternatively, remap everything to AZERTY and type blindly.
It is bound to be different from typing on a French keyboard because it's QWERTY and not AZERTY.
This sounds a lot like exceptions from conventions that arent standard to begin with, that are a further de-tour from how you type those languages.

How to type french

1. learn how to remap

2. remember remapped accent grave for meta+AEU

3. remember special letters ç and œ on  meta+CO

4 learn how dead keys work

4.1 learn different method of initiating dead-keys

4.1.1 use dead-key method for typing accent aigu é

4.2 or remember remapped accent aigu for meta+ W

       ./ or remember remapped accent aigu for meta+ R

This seems to be the list, we have not yet answered why it differs so much from how the French type French
 
Last edited by a moderator:
Well, we can also make dedicated French keymats if you like. Making the default keymat standard AZERTY is also an option, but then most of the rest of the world would be pissed, including me.
 
Back
Top