It's the keyboard layout.

[comradekingu]

They are, i changed dedicated printscreen for the AltGr, so all layouts have only optional shoulders.

 

[Haraldur]

Here's another variant, avoiding Meta+Shift for punctuation symbols, and moving Ins/Del to the action buttons:

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

Obviously more letters get Meta-labels now, but vowels and C N S are still free of Meta-labels so the default mapping could include Ä € Ö Ü ç ñ ß, with some spare room at W, T, Y, I.

Regarding Insert and Delete vs + and -, is there something I miss when it comes to the utility of Delete and, especially, Insert? - deserves to be a dedicated button much more than Insert, and + somewhat more than Delete, judging from my own use on a full PC keyboard. Your placement (previously) of + and - on the action buttons seems, to me, to be a major benefit.

 

[slaeshjag]

^ It depends on use cases. Personally, I don't really use + much at all, however both delete and insert are keys I use quite a bit.

 

[comradekingu]

buttoncluster+2 arent keys in the sense that they are buttons. Putting - and + here as + and - just meddles together things that are functionally and keyboard-wise seperated.

The reason why they cant be there as key-buttons, is because if you use them as game buttons, you lose the ability to use them as - and +.

You may want to type - in a game, and many games use - and + nativly. Whereas insert and delete is useless in a game, same with pageup, pagedown, home and end.

The reason why printing insert and delete as + and - doesnt work, is because people may think they are actual buttons, since + and - is close to that area on keyboards.̈́'

The best ive been able to do about it is: 

View attachment 11115

 

[Saber]

Then you have the problem of accidentally meta+q-ing.  Shoulder-operation of anything is not obvious.

Lets say you want to write a big Q, and mistake shift for meta, when they are on the same side shoulders.

Thats the end of your application, and the start of a bad relationship with the keyboard.

There's a bunch of coulds that may happen with the keyboard. Probably a rarer one there comradekingu, but they'll always be something to tradeoff. Not to toot my own horn here, but this is why we should quell our overreliance on the shoulder buttons, as I've done in my proposals v2(revision) and v3(ignore the lowest row's centered spacebar for a moment as it pertains to this discussion), and why two Shift keys and maybe two AltGr keys(as shown with v3) on the keyboard might be a good plan.

Shoulders as backups ideally, at least where Shift and AltGr values are concerned. Tab as one of the smaller face buttons(the lower one like I have it in my other v3 layout in my sig) and Escape where Menu is(with Menu on AltGr + Spacebar). These are some options to ponder.  

Three shift keys (two on the keyboard, one as a shoulder button) is problematic. Three Fn/Meta keys is problematic for the same reason. Modifiers come in pairs, and that's what standard software expects: L_SHIFT and R_SHIFT, L_ALT and R_ALT, L_CTRL and R_CTRL, L_META and R_META. They do not come in triplets. So if you want to have three shift keys, there are only two options:

1. invent a new keycode (say, S_SHIFT, for Shoulder Shift), and configure xkb etc to make it behave exactly like a Shift key. The problem is that lots of software will not recognize it (because it is not a standard key), so it will be hard to map game functions to it etc.
2. map two different physical keys to the same keycode, e.g. left keyboard shift to L_SHIFT, right keyboard shift to R_SHIFT, shoulder shift also to R_SHIFT. This means it is impossible to distinguish those two keys (e.g. shoulder shift and right keyboard shift). This also means it becomes possible to have 'impossible' sequences of key events, e.g. two [R_SHIFT DOWN] events following one another without a [R_SHIFT RELEASED] in between, which will cause some software to get confused.

Also, we have a keyboard with less keys than a normal full keyboard, so if you ask me, it makes no sense to make it have more redundant duplicate keys.

Shoulder modifiers are not just a "backup option", they will be the main modifiers for most users. ED is a notable exception. Shoulder buttons are an extremely nice mechanism to implement modifier keys, it is arguably more efficient than how it is done on a normal keyboard, so it is definitely something we should optimize for. Although I agree that there should be a backup option in case you can't easily use the shoulder buttons (like when the Pyra is sitting on a table).

We'll see how it ends up. This might be another getting worked up over nothing situation which tends to happen often around here. There will be two keyboard Shift keys even if both of them must be Left Shift(like you suggested before, remember). 

 

[comradekingu]

From what i understand. You can have left and right alt, and AltGr is different from right alt, even though i cant remember havent seen any keyboard with all 3.

Still not aware of there being a difference between shifts, so for all intents and purposes it can be two instances of the same key.  It worked on the pandora, thats the extent of my knowledge.

 

[_wb_]

From what i understand. You can have left and right alt, and AltGr is different from right alt, even though i cant remember havent seen any keyboard with all 3.

Still not aware of there being a difference between shifts, so for all intents and purposes it can be two instances of the same key.  It worked on the pandora, thats the extent of my knowledge.

Left and Right Shift are different keys, and that's how they are distinguished. That's why you can use the shoulder buttons (one of which is RShift) in PNDManager to navigate between tabs, while still being able to use keyboard Shift  (which is LShift) to enter capital letters when you're writing a comment.

 

[_wb_]

Here's another variant, avoiding Meta+Shift for punctuation symbols, and moving Ins/Del to the action buttons:

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

Obviously more letters get Meta-labels now, but vowels and C N S are still free of Meta-labels so the default mapping could include Ä € Ö Ü ç ñ ß, with some spare room at W, T, Y, I.

Regarding Insert and Delete vs + and -, is there something I miss when it comes to the utility of Delete and, especially, Insert? - deserves to be a dedicated button much more than Insert, and + somewhat more than Delete, judging from my own use on a full PC keyboard. Your placement (previously) of + and - on the action buttons seems, to me, to be a major benefit.

I agree, which is why in my main proposal (http://www.keyboard-layout-editor.com/#/layouts/e1b05961a2c31a6b89288597b9642ae6) I still have (numpad) + and - on the action buttons. I even have this covered:

The reason why they cant be there as key-buttons, is because if you use them as game buttons, you lose the ability to use them as - and +.

You may want to type - in a game, and many games use - and + nativly. Whereas insert and delete is useless in a game, same with pageup, pagedown, home and end.

In my main proposal, you still have the regular - and + at Meta+M and Shift+Meta+Space. Applications and games can tell the difference between regular + - and numpad + -, so there's no issue.

Also, you can turn that argument in either direction: you say that Ins and Del are useless in a game, but I can very well imagine that there are games where you use Ins and Del, maybe to reorganize an inventory or something.

 

[ible]

There will be two keyboard Shift keys even if both of them must be Left Shift(like you suggested before, remember). 

If that really is a constraint, along with the "Only hardware keys for the top buttons", I would do something along the lines of this guy:

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

I don't have a strong preference for the location of the diacritic keys, so I don't mind them being shuffled around, but I'd want everything else fixed .

I designed the layout to do well for coding/mathematical things.

 

[oxym]

This is not going to get much love, I predict. Still, here's my take:

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

It's basically US-International layout with AltGr changed to Meta to avoid three Alt keys. I didn't put any labels for Meta+Letter since I think those could be defaulted to US International altgr combos but be freely reassignable. The main feature is probably the dreaded driver-level modifier Fn, that makes it possible to actually have every key on the keyboard from the software perspective, even if it's behind Fn. As far as I can tell, all shift-combos should be correct as well.

(EDIT: Tried adding numpad keys for completeness, but the site says the layout became too large. Oh well.)

I have a question: how to produce keys like: [ ] ` ' = ;

Pressing Fn + shift produces caps lock

Pressing Fn + meta produces compose

Should a combo consist of caps lock and a letter?

 

[codifies]

@_wb_ re: http://www.keyboard-layout-editor.com/#/layouts/0ae20c3670099feed1b2d636a2b9eeb1


Just a thought as shift is going to be used more often than meta (yes?) Would it not be better on the edge of the keyboard (ie swapped with meta)

 

[bzar]

I have a question: how to produce keys like: [ ] ` ' = ;


Pressing Fn + shift produces caps lock


Pressing Fn + meta produces compose


Should a combo consist of caps lock and a letter?

By doing Shift-Fn, not Fn-Shift. If you consider this from the driver's point of view it makes perfect sense. I have considered taking the Fn-combinations out of the modifier buttons to get rid of this issue, though they are very conveniently placed in their current location. OTOH caps lock is already shift-shift, and compose could live elsewhere.

EDIT: Shift-shift caps lock is a bit bad though, since it's not actually 100% compatible with US International. Maybe I'll just put caps lock and compose on some non-modifier keys with Fn.

 

[_wb_]

@_wb_ re: http://www.keyboard-layout-editor.com/#/layouts/0ae20c3670099feed1b2d636a2b9eeb1


Just a thought as shift is going to be used more often than meta (yes?) Would it not be better on the edge of the keyboard (ie swapped with meta)

Yes, that makes sense I guess. Not sure if Shift is actually going to be used more often than Meta, I suppose it depends on the use pattern. I'm also not sure if the edge keys are really much easier to press than the penultimate keys. But obviously you can easily modify my proposal to swap Meta and Shift, and if other people also think that it would be better, I'll change my 'official' proposal accordingly.

I personally don't care much about the keyboard Shift and Meta since I would use the shoulder buttons all of the time.

Meanwhile, here is another variant of the above: http://www.keyboard-layout-editor.com/#/layouts/7b64346876b1c5a3a051ae8a7c9b0a7e

I'm a bit torn between layouts that have { } : ? as shifted [ ] ; / like on a normal keyboard, and layouts which have them separately, like on the Pandora. Avoiding Meta+Shift combinations is slightly more efficient, but it comes at the price of having more pre-defined Meta+letter combinations, and less out-of-the-box compatibility with DOSBox/Qemu etc. With an easily mashable keyboard Meta+Shift combo, and hopefully an easy to perform L1+L2 shoulder Meta+Shift combo, I think the efficiency difference might be small enough to still prefer layouts where { is Shift+[ etc, but I'm not completely convinced in either direction.

 

[codifies]

How would you press control C if placed on a desk?

 

[Wally]

How would you press control C if placed on a desk?

You plug in a keyboard.

 

[codifies]

How would you press control C if placed on a desk?

You plug in a keyboard.

defeatist !

 

[_wb_]

How would you press control C if placed on a desk?

SELECT+C. Like on the Pandora, START and SELECT are L_Alt and L_Ctrl respectively.

Also, I expect that at least one pair of shoulder buttons should actually still be usable, albeit somewhat inconveniently, when the Pyra is placed on a desk.

 

[bzar]

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

Updated, moved caps lock and compose away from modifiers to remove confusion regarding modifier pressing order. Now modifiers can be pressed in any order before the modified key for thje same result.

I considered swapping Fn/Meta and comma/period to be more in line with pandora, but decided having Fn on the opposite side of the most used Fn-modified keys is more important. Moving only one of comma/period would also be weird.

For shoulder button modifier people all the Fn-modified keys can also be mapped to Meta-combos, so you'll get the best of both worlds

 

[codifies]

The more different layouts I see without shift in the bottom left the more I think it needs to be there but I just can't exactly say why? Would it make it more convenient? Or it it purely because that's where I've seen it on every "normal" keyboard and my subconscious is failing to realise that this *isn't* a normal situation ...

 

[_wb_]

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

Updated, moved caps lock and compose away from modifiers to remove confusion regarding modifier pressing order. Now modifiers can be pressed in any order before the modified key for thje same result.

I considered swapping Fn/Meta and comma/period to be more in line with pandora, but decided having Fn on the opposite side of the most used Fn-modified keys is more important. Moving only one of comma/period would also be weird.

For shoulder button modifier people all the Fn-modified keys can also be mapped to Meta-combos, so you'll get the best of both worlds

So basically you would map all the Meta-keys to do exactly the same as the Fn-keys (so you can also use the shoulder button). But what happens then if you want to use F-keys in a game that also uses the shoulder buttons? How does this solve any problem?

To me, being able to input F-keys and punctuation symbols with just one thumb press per key/symbol (that is, using shoulder modifier(s)) would be a very important advantage of the Pyra keyboard compared to the Pandora one, and since we have four shoulder buttons, it should be possible. So all the labels you have as Fn labels, would have to be also mapped as Meta-combos. But then why still have Fn? Yes, I understand the difference between Fn+5 (which would send a low-level F5 event) and Meta+5 (which would be seen as a Meta event and a 5 event, and xkb or something like that would translate that to F5), but this will just confuse everyone if you do it like this. Either Meta or Fn feels redundant here. Of course you could use them in different ways to, e.g. Meta+O is Ö while Fn+O is [{, but then you lose the shoulder button method for one of them.

If you only have Meta, it should still be possible to let R_Meta (the shoulder button) do something else than L_Meta (the keyboard Meta) in those rare cases when you have an application that uses both L2 and the F-keys or punctuation symbols. You can still use Super or one of the Alt keys if you need more layers of symbols. I really don't think it's a good idea to have both Fn and Meta, it creates more problems than what it solves.