Unofficial Keyboard Layouts

[_wb_]

In Dutch, you don't need any special letter frequently, but you do need ... â, ê, ô, œ and ç every now and then

Your Dutch must be different from mine (i.e. Flemish ). I don't recall ever writing those in Dutch.

Well those are of course mostly used for loan words like enquête, œuvre, façade, and so on. Or names like François. But I guess such words and names are more common in Belgium than in the Netherlands.

The "wrong" here is the categorizing people which means to say one group is more than another because of something. "Lusers" as you put it versus "Powers". All may be purchasers once or many times and all will use the product or they won't. That's not the error in thought here and has nothing to do with how simplistic the GUI will be for the skillset of the person staring into the monitor. What is is one set is devalued over another because of the inferiors inability or desire to learn.

I'm not saying that power users are superior and lusers are inferior. Many people I know (e.g. many of my family members) are lusers, and there's nothing wrong with them and I don't consider them inferior human beings for that .

Sometimes it's good to have an interface / programming language / hardware design / whatever that is designed so that it prevents you from shooting yourself in the foot. But sometimes that is too restricting / cumbersome / inconvenient if you know what you're doing and you want to do it efficiently.

Of course it's best to have the best of both worlds if possible. E.g. on the Pyra keyboard we will probably have 3 shift keys: left, right, and shoulder shift. Now there are only two standard scancodes for shift, and I think it would be a bad idea to make two different keys produce the same scancode. For a regular user who just uses those keys as shift, it does not matter. But for a power user, who wants to remap keys (e.g. right shift to compose key or whatever else), it would be limiting to have it like that. So that's why I propose to have the right shift key on the keyboard produce the scancode for e.g. Super (aka the Windows key), and have a default configuration that makes it behave exactly like a shift key. Regular users couldn't tell the difference. But power users get an extra key out of it.

 

[Saber]

Of course it's best to have the best of both worlds if possible. E.g. on the Pyra keyboard we will probably have 3 shift keys: left, right, and shoulder shift. Now there are only two standard scancodes for shift, and I think it would be a bad idea to make two different keys produce the same scancode. For a regular user who just uses those keys as shift, it does not matter. But for a power user, who wants to remap keys (e.g. right shift to compose key or whatever else), it would be limiting to have it like that. So that's why I propose to have the right shift key on the keyboard produce the scancode for e.g. Super (aka the Windows key), and have a default configuration that makes it behave exactly like a shift key. Regular users couldn't tell the difference. But power users get an extra key out of it.

I have zero objections to your idea if it can be done. It's quite good, but I remember we talked in another thread about the Pyra key becoming Super instead of another hacked Context Menu key a la the Pandora key. If Pyra were Super, then "Right Keyboard Shift" might be Menu or Compose perhaps. Whatever it becomes it's a sound idea from you.

I'm almost finished(again) with my version of the layout. I'll post it within the week. I'm not so rigid to think I have it perfect, so any feedback from anyone is welcome.

 

[szr]

Of course it's best to have the best of both worlds if possible. E.g. on the Pyra keyboard we will probably have 3 shift keys: left, right, and shoulder shift. Now there are only two standard scancodes for shift, and I think it would be a bad idea to make two different keys produce the same scancode. For a regular user who just uses those keys as shift, it does not matter. But for a power user, who wants to remap keys (e.g. right shift to compose key or whatever else), it would be limiting to have it like that. So that's why I propose to have the right shift key on the keyboard produce the scancode for e.g. Super (aka the Windows key), and have a default configuration that makes it behave exactly like a shift key. Regular users couldn't tell the difference. But power users get an extra key out of it.

I have zero objections to your idea if it can be done. It's quite good, but I remember we talked in another thread about the Pyra key becoming Super instead of another hacked Context Menu key a la the Pandora key. If Pyra were Super, then "Right Keyboard Shift" might be Menu or Compose perhaps. Whatever it becomes it's a sound idea from you.

I'm almost finished(again) with my version of the layout. I'll post it within the week. I'm not so rigid to think I have it perfect, so any feedback from anyone is welcome.

If the Pyra key is going to be Super (aka the Windows/Command key), then maybe the extra (keyboard right) shift key could be Meta or Hyper (or any other key that is rarely used out in the wild or even seen on a PC keyboard) rather then Super. That seems to make more sense to have that sort of key mapped by default to right-shift and allow it to be remapped by the user as they see fit while still keeping usable separate right and left shift keys.

 

[God Ginrai]

Shift-Enter is used in pretty much any application that uses enter for submit so that you can insert newlines.

Such as?

Uhh, off the top of my head... Any IM client I've used since 1998 as well as Facebook and Flickr.

-God Ginrai

 

[comradekingu]

3 shift keys is 2 more than a clever default.

I use ctrl+enter for newline.

 

[_wb_]

Of course it's best to have the best of both worlds if possible. E.g. on the Pyra keyboard we will probably have 3 shift keys: left, right, and shoulder shift. Now there are only two standard scancodes for shift, and I think it would be a bad idea to make two different keys produce the same scancode. For a regular user who just uses those keys as shift, it does not matter. But for a power user, who wants to remap keys (e.g. right shift to compose key or whatever else), it would be limiting to have it like that. So that's why I propose to have the right shift key on the keyboard produce the scancode for e.g. Super (aka the Windows key), and have a default configuration that makes it behave exactly like a shift key. Regular users couldn't tell the difference. But power users get an extra key out of it.

I have zero objections to your idea if it can be done. It's quite good, but I remember we talked in another thread about the Pyra key becoming Super instead of another hacked Context Menu key a la the Pandora key. If Pyra were Super, then "Right Keyboard Shift" might be Menu or Compose perhaps. Whatever it becomes it's a sound idea from you.

I'm almost finished(again) with my version of the layout. I'll post it within the week. I'm not so rigid to think I have it perfect, so any feedback from anyone is welcome.

If the Pyra key is going to be Super (aka the Windows/Command key), then maybe the extra (keyboard right) shift key could be Meta or Hyper (or any other key that is rarely used out in the wild or even seen on a PC keyboard) rather then Super. That seems to make more sense to have that sort of key mapped by default to right-shift and allow it to be remapped by the user as they see fit while still keeping usable separate right and left shift keys.

I would make what used to be the Fn key on the Pandora, a Meta or Hyper key on the Pyra, and label it Meta because that sounds cool. I wouldn't make it AltGr, because I don't think there's an easy way to have two Alt keys and two AltGr keys (I think nearly anything expects either two Alt keys or one Left Alt key and one AltGr key, not four Alt keys), and also "AltGr" sounds a bit lame and long as a label, it adds confusion with Alt, and the reference to Alternate Graphics is weird if some of the AltGr combos are doing things like Wifi toggle or F1-F12, which has nothing to do with producing alternative graphical symbols. We could also make it a Super key, but that is a modifier key that is actually used by some applications, so it's probably better to avoid that for something that is intended to work like an AltGr/Fn key.

The Pyra key should be the Menu key, since that is what it maps to on the Pandora, and why break backwards compatibility?

It's slightly illogical that a logo key is not a Super key, but that's how it is.

So that means we don't have any Super key yet, and putting it on the right keyboard shift makes sense (also since the actual Right Shift key should already be the L1 shoulder button for backwards compatibility). We could even put a small Pyra logo on that key, and put the label "MENU" on the Pandora button (so you get START/SELECT/MENU).

 

[WizardStan]

Uhh, off the top of my head... Any IM client I've used since 1998 as well as Facebook and Flickr.

Same question to you then: when you tried these things on the Pandora and found they didn't work as intended, why didn't you report it as a bug?

 

[Saber]

Some changes to the layout. :wub:

Placed Start and Select alongside eachother. Don't know why this wasn't done from the beginning but we get another key out of it albeit unofficial.

Pyra is reverted back to the hacked Menu key it was. Same as on the Pandora.

Moved the trio Scroll Lock, Pause/Break, and Print Screen back under Fn + (Y)  (B )  (X) buttons.

Compose mode is now on Fn + Spacebar.

Thoughts?

 

[God Ginrai]

Same question to you then: when you tried these things on the Pandora and found they didn't work as intended, why didn't you report it as a bug?

Honestly, it's because I don't use the internet capabilities of my Pandora much. I use it mainly as a gaming system.

-God Ginrai

 

[WizardStan]

Honestly, it's because I don't use the internet capabilities of my Pandora much. I use it mainly as a gaming system.

So it never actually bothered you?

 

[God Ginrai]

So it never actually bothered you?

I never said it bothered me. You asked where this key combination was used, I gave you examples. The fact that someone has been arguing for it that made you ask that question should be proof that it bothers some people.

-God Ginrai

 

[WizardStan]

Fair enough, that is what I said. It was alanjf I had followed up with asking specifically about problems had on the Pandora.

That's what I was ultimately getting at anyway, trying to figure out how it could have gone 4 years now without anyone questioning why shift-enter didn't work the way they thought it should.

 

[alanjf]

Fair enough, that is what I said. It was alanjf I had followed up with asking specifically about problems had on the Pandora.


That's what I was ultimately getting at anyway, trying to figure out how it could have gone 4 years now without anyone questioning why shift-enter didn't work the way they thought it should.

I apologize for not being more clear. I don't have a Pandora. I'm rather new to this community and only found about it just a couple months ago. I am not new to computing though, and have known many common usages for shift + enter for a long time, so I thought it was good to voice that concern. I am sorry for any confusion.

 

[WizardStan]

I am sorry for any confusion.

Argh, no, I'm sorry. I'm confusing who is saying what to whom again.It was Caine who originally implied that the combination was absolutely needed and the target of my original "why didn't you report it when it caused a problem" question.

 

[_wb_]

I am sorry for any confusion.

Argh, no, I'm sorry. I'm confusing who is saying what to whom again.
It was Caine who originally implied that the combination was absolutely needed and the target of my original "why didn't you report it when it caused a problem" question.

Regardless of whether we can find evidence or not that people sometimes want to use shift-enter on the Pandora or on any other device, I think it's better not to overload multiple keys on one key except by using the Fn/AltGr/Meta modifier. The standard modifiers Shift, Ctrl and Alt should not be used to change keys like Enter, Insert, Delete, Backspace into something else.

Also, a compose key that is not a dedicated, easy to press key is not very practical. I'm fine with having Meta+RightShift as default compose key, because some people don't use compose at all so they won't miss it, but anyone who actually uses the compose key regularly will want to remap it to just RightShift. It would then be nice if the ISO compose key symbol would be included on the label of that key (besides the Shift symbol), e.g. something like this:

⇧ ⎄

if the color for Fn/AltGr/Meta is ◆.

 

[Saber]

I am sorry for any confusion.

Argh, no, I'm sorry. I'm confusing who is saying what to whom again.
It was Caine who originally implied that the combination was absolutely needed and the target of my original "why didn't you report it when it caused a problem" question.

Regardless of whether we can find evidence or not that people sometimes want to use shift-enter on the Pandora or on any other device, I think it's better not to overload multiple keys on one key except by using the Fn/AltGr/Meta modifier. The standard modifiers Shift, Ctrl and Alt should not be used to change keys like Enter, Insert, Delete, Backspace into something else.

Also, a compose key that is not a dedicated, easy to press key is not very practical. I'm fine with having Meta+RightShift as default compose key, because some people don't use compose at all so they won't miss it, but anyone who actually uses the compose key regularly will want to remap it to just RightShift. It would then be nice if the ISO compose key symbol would be included on the label of that key (besides the Shift symbol), e.g. something like this:

⇧ ⎄

if the color for Fn/AltGr/Meta is ◆.

Would L1's Right Shift be affected by the Fn key in your layout?

I think Fn + Spacebar is a wiser alternative and is simple to do without preventing someone who would want to use the Right Shift key with the Fn key from doing so. I agree with your statement about not having modifiers change keys like Enter and Delete except for the Insert key which I don't see used as often by most people to warrant a primary key position. 

 

[szr]

I am sorry for any confusion.

Argh, no, I'm sorry. I'm confusing who is saying what to whom again.
It was Caine who originally implied that the combination was absolutely needed and the target of my original "why didn't you report it when it caused a problem" question.

Regardless of whether we can find evidence or not that people sometimes want to use shift-enter on the Pandora or on any other device, I think it's better not to overload multiple keys on one key except by using the Fn/AltGr/Meta modifier. The standard modifiers Shift, Ctrl and Alt should not be used to change keys like Enter, Insert, Delete, Backspace into something else.

I agree, shift/alt/ctrl + ordinary-keys should behave as they would on a regular keyboard. At the very least emit the same scancodes they otherwise would. I think this may be quiet important in order to maintain consistency where if one were to connect an external keyboard to the unit.

 

[levi]

It's an issue with a pandora, but you only need to swap keyboard mappings when you connect an external keyboard.  The layout you switch to depends on the region of keyboard you connect of course, so its not like you're saving much by not making it necessary for certain keyboards.

 

[_wb_]

I am sorry for any confusion.

Argh, no, I'm sorry. I'm confusing who is saying what to whom again.
It was Caine who originally implied that the combination was absolutely needed and the target of my original "why didn't you report it when it caused a problem" question.

Regardless of whether we can find evidence or not that people sometimes want to use shift-enter on the Pandora or on any other device, I think it's better not to overload multiple keys on one key except by using the Fn/AltGr/Meta modifier. The standard modifiers Shift, Ctrl and Alt should not be used to change keys like Enter, Insert, Delete, Backspace into something else.

Also, a compose key that is not a dedicated, easy to press key is not very practical. I'm fine with having Meta+RightShift as default compose key, because some people don't use compose at all so they won't miss it, but anyone who actually uses the compose key regularly will want to remap it to just RightShift. It would then be nice if the ISO compose key symbol would be included on the label of that key (besides the Shift symbol), e.g. something like this:

⇧ ⎄

if the color for Fn/AltGr/Meta is ◆.

Would L1's Right Shift be affected by the Fn key in your layout?

No, because that one is the "real" RightShift and it has nothing to do with the right shift key on the keyboard. The keyboard right shift would actually be a Super key, which would be coded in software to behave by default as a Shift key and with Fn as a Compose key.

I want to put the Compose key symbol on a key that can be actually remapped to act as a dedicated Compose key. Obviously if you make Fn+Space or Fn+Enter act as Compose and put the Compose key symbol on those keys, that's fine as far as the default mapping goes, but I can't use Space or Enter as a dedicated Compose key, so I end up mapping something else to Compose and having more confusing labels on my keys than what would be possible in my proposal.

 

[comradekingu]

So if someone wants to remap a key that is arbritrary, it should be to the key that is arbritrary in the context? How about rethinking the whole right shift.

Shift does shift, alt does alt, no super, and no fn key, because that is a poor excuse of a button, and a horrible way to implement functions.

Make the colour of the writing on shift the same as what it alternates etc.

Space shouldnt be two buttons, because it serves no purpose that im aware of, other than to visually disrupt, and make remapping for dvorak harder.

Wizardstan noted: http://www.openpandora.org/downloads/PANDORA_Hackers_manual_v101.pdf  page 21 they are wired together, why why why.

And instead of reading "space" it could read |____|   as the case is with every other small keyboard.  Less visual clutter.