It's the keyboard layout.


Regarding the AltGr vs Fn convention...


IMHO they mean the same thing and can be used interchangeably as it appears that either naming convention will activate the AltGr code from the keyboard.
Not really.

Alt-Gr is Right-Alt

Fn is not a key.

I just say that with a developper point of View.

So

If you have Fn + 1 = F1, in an SDL software (for example), you press Fn + 1, and the software sees SDLK_F1

If you have AltGr +1 = F1, in that same software you see SDLK_RALT and SDLK_1

So you have to adapt, because you don't see a F1 key pressed.

You can continue the keywar...
 
Just to show how altGr+1=F1 isn't a good idea, here is what happens when you shift+numberrow on a Norwegian keyboard

!"#¤%&/()=?

This is altGr+

¡@£$½¥{[]}±

On us keyboards only 1 symbol is printed on the number-keys because they have the extra that they arent using for extended alphabet to put them on.

The keys to the right of P and L. Those can still be used as per US-standard norm, and conveniently they arent used for language input.

[] and {} if you add to that the button that is missing from US keyboards <> there, you have all brackets in one place.

The pyra has to use AltGr the euro way, since there is a shortage of buttons. Also the sequence cant be any one particular standard, because the numberrow doesnt have

13 keys. So you pick the most useful ones, try to fit as best possible with the different ones (all languages do it slightly differently) so that altGr

can be put on shoulder. It is then possible to input language with only the keyboard (sans shoulders) That makes it OK for beginners. :)
 
Last edited by a moderator:
I dont own a pandora and havent so i will digress to everyone elses genious and i havent seen it posted here but,  In all my linux distro i can change the keyboard layout and with KDE is in the settings to edit buttons also so in theory everyone could create thier own keyboard layout to their desire?   And if they can i could be nice to have a keyboard layout switch key (Altgr + Shift + Shift) so i could go from my gaming keyboard layout to my coding layout, to my ......   I suppose you are talking about what is typed on the actual keys so maybe some of the keys you are not sure about could be flex key icons like tux, and the pandora logo instead of < and >.  And if that is possible to do maybe turn off one of the number lights so I know which keyboard layout i am using?  Assuming you can turn off one of the keyboard lights.

As I said dont own pandora so will trust it current users expertise but was just thinking out loud.
 
AltGr isnt needed on the keyboard part, it can be on the shoulder,
I believe one of ED's unstated goals was to have all modifiers as both keys and shoulder buttons to accommodate both types of typists.
compose keys arent dedicated keys
Some keyboards do have dedicated compose keys. Some other users map the Win key (or others) to compose effectively making a dedicated key. The software underneath does what it needs to do, whether that is taken directly as a single key or mapped accordingly to shift-altgr is a matter of semantics and not really relevant.
And how do you imagine German keys implemented exactly?
I don't. I'm not German, I've never had to use those keys. I won't pretend to know what is best for them. Presumably they'll be secondary Fn keys, as they are in Grench's layout but someone who is German needs to confirm if that'll actually work for them.
If you want dedicated keys, then please explain what will non-German users do with those 4 keys?
Whatever they want. I'm not going to tell anyone what they can or can't do with keys. Personally I'll remap them to something I would use. Not sure what that will be yet though. Or maybe I'll leave them as is: foreign characters come in handy sometimes.Given the choice between an unlabeled key that everyone needs to manually bind and remember what it is vs. a labeled key for 20% (a guess) of the use base and only 80% have to remember what it is I'm going to champion the latter. 20% benefiting from it at no cost to everyone else is better than no one benefiting at all.

Alt-Gr is Right-Alt Fn is not a key.
That's the point though, is AltGr on the Pyra Right-Alt? Or is it just another key? At the moment it is just another key that happens to be labeled "AltGr" that is doing something similar (but not identical) to what the AltGr does on standard keyboards, which is exactly the same as what the Fn key on the Pandora does. This is why I'm with Grench in not calling it AltGr, it'll cause confusion in expecting it to actually be identical to the AltGr on a full sized keyboard and we just can't do that.
If you have Fn + 1 = F1, in an SDL software (for example), you press Fn + 1, and the software sees SDLK_F1

If you have AltGr +1 = F1, in that same software you see SDLK_RALT and SDLK_1
All the more reason to continue to call it Fn and not AltGr.
so in theory everyone could create thier own keyboard layout to their desire? And if they can i could be nice to have a keyboard layout switch key...
Once again, this has been pointed out several times in the last 11 pages, it is a given that people will be able to change the layout internally to whatever they want but what is printed on the keys will be considered the default. We need to find something that works reasonably well and isn't needlessly confusing to others.
flex key icons,
Too much money. We're lucky we're getting a backlit keyboard at all.
Assuming you can turn off one of the keyboard lights
As far as I know, all LEDs in the keyboard matrix are activated on a single GPIO, either they're all on or all off.
 
Why do we need ANY specialized characters on the keymat ?

the better place for them is printed on the case next to the key, or have an overlay that can be clipped onto/over the keyboard with the keys poking through

This means just one keymat that is dedicated to programming / terminal tasks - with any specialized characters provided by mapping and simple printing - rather than multiple keymats (probably not practical) or one keymat that tries to make everyone happy and fails for everyone...

It is simply not possible to make a single keymat that will be convenient for all users and all languages
 
Wikipedia said:
Fn is a modifier key, and works like other modifiers keys, such as Ctrl, Shift and AltGr. For a standard modifier key, the microcontroller inside the keyboard sends a scancode for the modifier itself, which is then interpreted by the operating system and combined with other simultaneous key-presses. The Fn key is a form of meta-modifier key, in that it causes the operating system to see altered scancodes when other keys on the keyboard are pressed. This allows the keyboard to directly emulate a full-sized keyboard, so the operating system can use standard keymaps designed for a full-sized keyboard. However, because the operating system has no notion of the Fn key, the key can not normally be remapped in software, unlike all other standard keyboard keys.
(ref) Emphasis mine. Fn is NOT a software modifier key like the others. It's specifically a hardware modifier key. Do not want.
 
Last edited by a moderator:
Why do we need ANY specialized characters on the keymat ?

the better place for them is printed on the case next to the key, or have an overlay that can be clipped onto/over the keyboard with the keys poking through

This means just one keymat that is dedicated to programming / terminal tasks - with any specialized characters provided by mapping and simple printing - rather than multiple keymats (probably not practical) or one keymat that tries to make everyone happy and fails for everyone...

It is simply not possible to make a single keymat that will be convenient for all users and all languages
At this point, It's just not possible to make a layout everyone will adore completely. I wish it was, but people do want some characters included and attempts have been made to accommodate them without stickers or overlays or case reprints(probably cost prohibitive). For instance, with the grave diacritic _wb_ said it best earlier in this thread when he talked of how we only need a single backtick key in the layout if it's set in software that this character will be generated only if followed by anything but a vowel or letter that normally has the grave diacritic. It's a good idea. Hopefully it can be used.

WizardStan, thanks for explaining that earlier about AltGr. It makes sort of sense now. Was having a time wrapping my head around the why of it all.  :)
 
Last edited by a moderator:
Wikipedia said:
Fn is a modifier key, and works like other modifiers keys, such as Ctrl, Shift and AltGr. For a standard modifier key, the microcontroller inside the keyboard sends a scancode for the modifier itself, which is then interpreted by the operating system and combined with other simultaneous key-presses. The Fn key is a form of meta-modifier key, in that it causes the operating system to see altered scancodes when other keys on the keyboard are pressed. This allows the keyboard to directly emulate a full-sized keyboard, so the operating system can use standard keymaps designed for a full-sized keyboard. However, because the operating system has no notion of the Fn key, the key can not normally be remapped in software, unlike all other standard keyboard keys.
(ref) Emphasis mine. Fn is NOT a software modifier key like the others. It's specifically a hardware modifier key. Do not want.
They're actually speaking here of labeling the key "Fn". Underneath/internally it will remain AltGr. The reasoning behind it is so no one will confuse it with a regular AltGr key which behaves differently to our AltGr. Although, instead of calling it "Fn", it could be the "Sym" or "Mod" key. It's only the label on the cap that was recommended be changed. It's up to others to decide what to call it though.  :)
 
Last edited by a moderator:
I don't want to argue about semantic, but I do agree with the definition that Fn is a hardware modifier (or looks like that for userspace apps) were AltGr is Right-Alt and therefore, a software modifier (at list, on any french laptop keyboard, where both AltGr and Fn can be found).

strongly advise against having AltGr/Fn/Whatevername key to be a software modifier (in the user-space point of view), has it will require mostly all applications to be adapted just to take a F1 keypress.

The Fn-key mecanism of the Pandora is good (Fn keypress is not seen), and there are just a few glitches related to keymap that are fixable per software (main case is "Fn" + ">" for ":", where a standard US keyboard expect "Shift" +  ";"

Now, do whaterever you want, but don't expect the Debian library to just run in plug'n play mode with F1 beeing Modifier + "1"
 
I don't want to argue about semantic, but I do agree with the definition that Fn is a hardware modifier (or looks like that for userspace apps) were AltGr is Right-Alt and therefore, a software modifier (at list, on any french laptop keyboard, where both AltGr and Fn can be found).

strongly advise against having AltGr/Fn/Whatevername key to be a software modifier (in the user-space point of view), has it will require mostly all applications to be adapted just to take a F1 keypress.

The Fn-key mecanism of the Pandora is good (Fn keypress is not seen), and there are just a few glitches related to keymap that are fixable per software (main case is "Fn" + ">" for ":", where a standard US keyboard expect "Shift" +  ";"

Now, do whaterever you want, but don't expect the Debian library to just run in plug'n play mode with F1 beeing Modifier + "1"
I may be wrong here but if there's a second "AltGr" key, without sticky function, on the L2 Shoulder button, it must be a software modifier. If it's the hardware variety like Fn on the Pandora I think was, then the L2 shoulder button will only output a scancode when another key is pressed after it. This obviously wouldn't work well in games or applications.   
 
So, I'm of a mind that we should use Fn as the nomenclature for what is really AltGr behind the scenes. It will cut down on a lot of confusion.


Can I live with two AltGr keys and two Alt keys on one device - sure. But I would hate to write the instruction book.
My laptop, like every other laptop I've ever owned, has both an fn key and an altgr key :p

Fn is NOT a software modifier key like the others. It's specifically a hardware modifier key. Do not want.
Fn on the Pandora is a software modifier.
It is only a software modifier in the sense that a driver handles it. No userspace application sees the fn key as a modifier.
 
I strongly advise against having AltGr/Fn/Whatevername key to be a software modifier
Agreed. Yet another reason to be against calling it AltGr. AltGr is a software modifier and this AltGr cannot be a software modifier.Everyone expects that in userspace "ALGRFNMETAMODWHATEVER"+<key> will produce the scancode for the key being described, even if in some cases that scancode is actually multiple scancodes for "right alt" + "whatever_key".

main case is "Fn" + ">" for ":", where a standard US keyboard expect "Shift" +  ";"
Grench's layout solves this by making ";" as "ALGRFNMETAMOD" + "G", and ":" as "Shift" + "ALGRFNMETAMOD" + "G". It actually works out very nicely, assuming it is possible on the keyboard matrix to press shift, altgrfnmetamod, and G all at the same time. It should be, we should only find 2 keys which won't work and we can work around those.
 
It is only a software modifier in the sense that a driver handles it. No userspace application sees the fn key as a modifier.
Fair point. I think I got distracted there.Then for our purposes the Pandora's Fn key is a hardware modifier and for the Pyra it absolutely must be the same regardless of B-Zar's objections. Like ptitSeb says, we can't call it AltGr, have it spit out the "right alt" + "1" scan codes, and expect software to realize we mean F1.
 
Most layouts I've seen thus far have not had a Fn (hardware or driver-simulated) key, but various meta/altgr/hyper variations. I think (gut feeling, no strong opinion) Sym is usually like Fn and Mod is a software modifier. Now, If we had both Fn and AltGr (or meta, which I'd probably prefer because of less expectations about what it does) that'd be fine. Having only Fn in addition to already pretty much taken software modifiers Shift/Ctrl/Alt would mean no room to map custom stuff, which is the case for pandora. I don't want to not have dysfunctional software because we don't have real F-keys, but I also don't want to have zero compatibility-retaining wiggle room for one-modifier custom keys.
 
Will there be a need to change keyboard layout just for external (USB, BT) keyboard to work correctly? What about using external and built-in keyboards simultaneously? Will all buttons be remappable, including Key/Logo/Power/USB/BT row?

Put the P+2 and L+2 keys in the P+2 and L+2 positions, like a keyboard. Label them according to US/UK convention, because that is the biggest market.
M+2/3 as well.
Since ISO keyboards are all the same amount of typing-keys (And ANSI for case of argument) in the same positions, you can satisfy to great extent the need of all europeans by implementing the extra letter keys in the positions they are supposed to be in.
Someones accentuation is someone elses extended/"regular letters"
 Not just europeans. Many layouts are just ISO/ANSI, including the numbers and symbols to the right of letters, remapped, aren't they?

You seem to be assuming that a block of 3-4 keys is enough for everyone. This is true for German and the Scandinavian languages, but most other European languages need more than that.
True.
Russian layout has regular letters on P+2, L+2, M+2 and normal layout is not very usable on Pandora, to the point I just used on-screen keyboard.
 
P+2 would dictate that there is only room for -one- key in the lower left for shift, alt, ctrl or Fn.

M+2 AND having numbers on the top row is simply -impossible-.

Carry on.
 
You don't need any of those in the lower left. Actually i cant see a reason why they should be. Handheld use with pinkey-fingers active
isnt as easy as the mental transition from 10fingers. Its a fallacy to pretend it isnt.

Shift: should be close to . since that is a frequent chain of events. And they all have to be on the right since as you said, space on
the left is limited if you want P+2. No loss though.

Ctrl: As with shift, there should be a keyboard part only, without the use of shoulders to type this. So it doesnt have to be lower left.
Also lower left is much much worse a position on 2-thumbs than it is on a 10finger keyboard. The need for ctrl as an effective key aligns with
shoulders because its a more technical thing than the use-case of someone who has enough with trying to figure out the keyboard-part alone. (beginner)

Fn: Any modifier that is in the lower left (or lower right) alone, (since you cant dual-fn or other such) means typing Fn+anything is a lesser use. Thats not so good, increasingly so the more
functionality the modifier has, especially basic functionality used often.

Numbers on anything but top row just facilitates a "im unhappy and have good reason to"-situation, so yes. The people who need M+2
are fortunately not the bread-and-butter. M+2 being the "i need 6-keys other than A-Z" we can at most give everyone 4, where one of
them is the shift-key. (since earlier mentioned, that should be a shoulder to get more efficiency out of the two-thumb paradigm)

A reminder here people that AltGr is Left Control and Right Alt, so any of the other possible Control and Alt combinations will be fine with the Spacebar key for whatever program needs it should we put say the Menu key on Spacebar to have a dedicated Escape key(as in my alternative v2c layout in my sig).
 
I'm not saying above that Escape will be moved to Menu's position, but it could be with only a minor imperceptible sacrifice.
I dont understand this. Is anything other than "space" or "|__|" printed on the space-key? Given a bar-key, how do people feel about staying with bar-look, and going double-duty, like this: http://boards.openpandora.org/uploads/post-2326-0-41907700-1427028696.png To me that is the good-compromise between those who want

a bar-key, and those who want more keyboard functionality. I think the losers are dvoraks, or something else where you need to use M+2 for typing, but that is the minority in this case. One that unfortunately cant be fully happy with the compromise that works for everyone else (given how you have print on the letters (pretending remapping is ok isnt ok. It is for the dvoraks, but they are very few, and the people you sell a lackluster M+2 idea to isnt a huge bonus)

Why do we need ANY specialized characters on the keymat ?
 
the better place for them is printed on the case next to the key, or have an overlay that can be clipped onto/over the keyboard with the keys poking through
 
This means just one keymat that is dedicated to programming / terminal tasks - with any specialized characters provided by mapping and simple printing - rather than multiple keymats (probably not practical) or one keymat that tries to make everyone happy and fails for everyone...
 
It is simply not possible to make a single keymat that will be convenient for all users and all languages
You are raising a lot of issues, let me try and solve them in a constructive manner:
Implied that we is the current community, (and an even more international one if the pyra keyboard is more international.) "Specialized" characters on the keymat makes it painful for others, and with those differing as much as they do, you have to rely on motorical memory rather than visual clues. Again, anything visual needs to be minimal, because more info, and especially non-standard info, is chaotic, and ruins everyones experience increasingly as you put everyones characters in.
 
There is a great deal of difference between doing everything over, and trying to do everything normally. One becomes chaotic quick, and the other falls short
of being perfect where perfection is its ability to be normal.
 
Since what we are working from is the basis of something that works for english people, and they are the single biggest group, they should get the default behavior.
On the pandora it was a factor of neccesity, that same limitation fails just as hard in 2010 as it will do in 2015. That is what we should improve on, without losing the working prospects of english/pandorakeyboard. That is after all the false positive basis the community was built on. Fortunately, there is little praise for its bad concepts. We can even do more of what it really does english/keyboards, meaning something that is in line with how they work, and why. Yes you have to condence the differences between layouts into one default. You however get some things for free, ISO and ANSI keyboards have the same amount of keys (minus <>) english is better for coding, international is better for respective regions. Fortunately the key difference is predominantly in
the typing letters outside of A-Z.
 
There is a design-win here, because in a standard way, that also means the default is better for coding, and that fits really nicely with what makes the pyra usergroup special. If it only suited them, it would be a nieche within a nieche. I see instead everyone happier when the full and broad appeal of the pyra is utilized. More sales mean better prices for everyone.
With expectations of a keyboard, its already a battle to implement a keyboard.
You can do that up until a point where it isnt feasible anymore. The number of keys on a pyra exactly facilitates 87-key behaviour.

If you try and save a key by doing double-duty on a key with expected behavior, like AltGr, then that is a loss (compared to fully functional AltGr).
The pyra keyboard can be a real keyboard in all aspects except for F-keys (dictated by the number of keys available)
(Fortunately F-keys are losing relevance, and are more 10finger desktop centric than nubs/touchscreen/handheld, but alas, they need
to be available at all times because of the user demographic.) This shouldnt mean losing AltGr, or a modified AltGr, instead it should
be an extra key, that is a F-key modifier.
Do one thing, do it well. It would be nice to have it called "F-" and a different colour, because that can be intuitivly picked up.
Fortnately, if the only functionality you depend on for that is F-keys, you also just need the people who need F-keys to understand it.
You dont bring any chaos if you solve the problem right at its
foundation.
 
Last edited by a moderator:
Strong vote for dedicated ESCape key (vim).

But most important: Software support (built-in from the start) to freely assign any key to any function.

Would it not be best if the keys could be easily exchanged physically?

Then a set of keys for any language could be sold and people would just switch the keys around any way they like (and use the software support to match the physical layout).

Blank keys should also be available so we would paint the symbols on them we want.
 
Last edited by a moderator:
Back
Top