elvissteinjr
Very Active Member
But weren't those only clickable when at least almost centered? I mean, I'd prefer to have mouse dragging being a possible thing.
Current Keyboard Layout
- Thread starter EvilDragon
- Start date
- Joined
- Jan 18, 2010
- Messages
- 11,418
Yeah it's kind of a drag(pun intended) that they're only clickable while centered. I suppose it can be good for toggles or something...
Saber
Advanced Member
- Joined
- Jan 23, 2012
- Messages
- 1,303
I think ED said so but in most cases it probably doesn't matter much. It depends on the user but if Insert isn't top priority to them they could always remap it's mini-button to an auxiliary left mouse click.
I think the idea was to use opposite nubs for mouse movement and left clicking. It has to be tested how well this works, but AFAICT most keyboard layouts were made under the assumption that this is not a problem. This could be extended in various ways, e.g. clicking the nub that is normally used for mouse movement temporarily switches the opposite nub into mouse movement mode allowing easy right click dragging, too.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
Wow - I take a few days to spend with family over the American holiday and a lot has happened here.
There are some very good things going on with this layout:
http://www.keyboard-layout-editor.com/#/layouts/37af15095b2aeedd169b0b5beb3bc9a6
There are also a few things that make it a bit of a train wreck.
No offense intended ED, but it looks like you completely skipped reading the vast majority of the keyboard threads. We all learned a lot. There are a few fundamental things that got skipped. I can provide more lengthy explanations, links, etc upon request on any of the topics. You asked for us to keep this short and I am going to try.
Fn/Meta behavior: The two Fn keys are two different keys with two different needs - but one common behavior. The shoulder Fn needs to create a unique keycode to the OS so that the OS can re-map it to something not Fn-like for games. The keyboard Fn must always perform as Fn. BOTH Fn keys need to behave to the OS as if they were a HARDWARE Fn - i.e. NOT generate just a key code, but instead they must fundamentally change the behavior of the other key pressed. Yes, this can happen at the driver level, but it must happen prior to the OS map.
Fn+Shift is not an option, it is and must be a rule: Every physical key on the keyboard (other than Lshift, Rshift, LFn, RFn, LCtrl, RCtrl, LAlt, RAlt) must have 4 'mappings' or 'layers', even if they are not explicit in the printing on the keys. It is easiest to think of the keyboard as TWO physical keyboards. One is the 'Normal' keyboard where each key has it's unshifted and shifted values. The second keyboard is obtained by pressing Fn. Fn, by it's definition tells the driver, "Switch to the Fn keyboard". The Fn keyboard ALSO has unshifted and shifted values available and should generate codes, whether those are directly mapped to symbols or not. ALL of the keyboard layouts that have F1-F12 keys on the Fn layer do this. Every F1-F12 Fkey MUST be able to be combined as:
Fkey, shift+Fkey, Alt+Fkey, Ctrl+Fkey, Alt+shift+Fkey, Ctrl+Shift+Fkey, Alt+Ctrl+Shift+Fkey, etc...
The fact that shift+Fkey is in that list AND the layouts having F1-F12 on the Fn layer means that Fn+Shift MUST exist.
DosBox, QEMU, X86 compiled Linux programs and "PC Gaming" are all potentially going to be a 'big thing' on the Pyra. Those bring with them a small amount of issues that are MUCH easier to solve now with the keyboard layout than the would be to change later through re-writing and fixing code. They are also another reason why the Fn behavior MUST appear to the OS as if it were a hardware Fn. DosBox and similar go straight to the driver and interpret the keyboard themselves as if it were a US standard layout. They cannot be easily re-mapped in software. What this means is, regardless of what you have mapped to shift+; DosBox will read :. The issue gets more annoying when something is marked that DosBox doesn't understand. Anything you have mapped at a base or Fn layer that isn't a base key will not be read. So, on your layout where Fn+A={ those programs will either do nothing or be confused because there is no { base key on a US keyboard. They'll only see Fn+D=[ IF the Fn is passed as a hard keyboard switch at the driver layer. Many very smart people have tried to 'fix DosBox', none have succeeded. The issue is fundamental in how DosBox reads direct key presses instead of combinations. DosBox is simply the easiest example of this issue, it is not restricted to this one emulator. The whole issue can be cured by, 'Maintaining key pairs from the US keyboard'. This is pretty simple, but DOES require that Fn+Shift be recognized as a 'real thing'.
Fn+Shift is a real thing - and a very handy thing. You will see that the majority of the layouts proposed place Fn and Shift next to each other instead of cross-keyboard on the Pandora. The Pyra has more keys than the Pandora did - and it's a great thing. The fact is, though, it is still short on keys and needs to make use of a second keyboard mapping. So by having Fn and shift next to each other, it becomes possible to chord them. I.e. press both Fn+Shift at the same time as a single press of two keys or 'mashed'. Acknowledging this feature allows the Fn layer's shift modification to be 'opened up'. A hardware-type Fn truly doubles the number of symbols that the Pyra's keyboard can produce. This means that a Fn layer key can produce both upper and lower case letters.
Understanding Fn+Shift gives the Pyra enough keys to map symbols in true US keyboard pairs (DosBox), have the most awesome PC Game controller ever (numbers and F1-F12 on same Fn layer), offer unparalleled international support with simple diacritics all while maintaining unencumbered English usage. It can all be done, but it would require a substantive reconsideration of the current keyboard approach.
http://boards.openpandora.org/topic/16872-and-now-for-something-completely-different-keyboard-option/?p=389806
Ctrl+Insert and Shift+Insert is a real thing. It is part of the CUA standard. It is expected by both Gnome and KDE. https://en.wikipedia.org/wiki/IBM_Common_User_Access
Pause/Break and PrtSc/SysRq should both be top layer keys.
Pause/Break is often used with Ctrl+Pause and Ctrl+Break. Pause then needs to be accessible with Ctrl.
PrtSc is often used in conjunction with Alt. Alt+PtrSc captures the current window (in Gnome, etc) into the copy/paste buffer. PrtSc then needs to be accessible with Alt.
Esc should be accessible, hard to press on accident and present during game play. My preference is on Fn+ top left key above the left nub.
Keyboard and LCD brightness with control for both up and down can be controlled on a single backlight key.
Normal: Screen backlight increase
Shifted: Screen backlight decrease
Fn: Keyboard backlight increase
Fn+shift: Keyboard backlight decrease
All radios AND USB can be controlled on a single IO Control key.
Normal: WiFi toggle
Shifted: Bluetooth toggle
Fn: USB toggle
Fn+shift: 4g toggle
However, a better method might be to have a 'hardware menu button' that pulls up a hardware menu in the OS. By doing it this way, it allows for many more things to be controlled in a central place without any 'button guessing'. On my more recent layouts I designated it on the top left corner above the nubs with the ≡ symbol.
Diacritics and International support:
There are a series of symbols that are commonly used to designate dead key diacritics.
,< .> /? '" `~
These also just happen to conveniently be US keyboard base pairs.
We also, conveniently, have a keyboard that does key, shift+key, Fn+key, Fn+shift+key.
This allows a certain magic to happen.
Normal `~ key is `
Shift+ `~ key is ~
Fn+ `~ key is the ` dead key for grave diacritics.
Fn+shift+ `~ is the ~ dead key for tilde diacritics.
By keeping these symbols as 'base layer', I.e. NOT on the Fn layer, it enables these 'easy diacritics' to happen.
,< .> /? '" `~
Shift+Shift as ShiftLock
Fn+Fn as FnLock
For the most part we can get around not having a dedicated 'CapsLock' key. However, it would be handy to still be able to lock the shifted layer if the user chose to. To solve this, since we have two shift keys, we can have shift+shift = ShiftLock. If the keyboard is in ShiftLock mode, holding shift then pressing a key would generate the unshifted value.
Similarly, we can do the same thing with Fn+Fn = FnLock. This would bring the Fn keyboard layer 'topside' in much the same way as ShiftLock would bring the shifted layer topside. Holding one Fn button when in FnLock mode would produce the UnFn layer value.
Yes, it would be possible to 'lock' both layers at the same time.
Why would German support be limited to the lowercase of Ü, Ö and Ä? They're letters - and they have an upper and a lower case. Yes, their lower case use is more common. But then, whey relegate these to the Fn layer at all? Why not have them on the top layer where they're just as easy to use as the English letters if it can be done without impacting the English keyboard. And while we're at it - lets put them in the same positions that they reside in on the German keyboard. For the longest time I thought this simply couldn't be done. The Pyra just didn't have enough keys to make it happen. I was wrong - it CAN be done and it should be fantastic.
So, PC gaming is going to be a thing on the Pyra. Halflife is already working on the Pandora using the new X86 Linux emulator code. Two of PC gaming's biggest genres are First Person Shooters (FPS) (Halflife type) and role playing games - often online, often massively multiplayer (Neverwinter Nights, WoW). Something these two genres have in common is extensive use of the number keys 12234567890 AND use of F1-F12. Sometimes BOTH are needed during the same game. Often one series or the other is expected to be easily modified with shift+, ctrl+ alt+. For these types of games, it would be a huge advantage to have both the number keys AND the F1-F12 keys be able to be on the same keyboard layer at the same time. I.e. be able to lock in a 'game mode' on the device to have game controls and all of 1-0 and F1-F12 available. Yep, that can be done too.
All of the above CAN be done. Two variations on that theme showing some of the open options:
http://www.keyboard-layout-editor.com/#/layouts/ee8d3bc8b446f99c027105d3810f8d07
http://www.keyboard-layout-editor.com/#/layouts/b76ffdc065642c07243bad385b4a06a8
Fn behavior understood and accounted for. Check.
DosBox and other software that reads keypresses at a driver-layer compliance. Check.
Ctrl+Ins Shift+Ins capable. Check.
Ctrl+Pause/Break capable. Check.
Alt+PrtSc capable. Check.
Screen and keyboard Backlight controls. Check.
Radio and hardware toggles controlled by easy to find 'Hardware Menu' button. Check.
Complete English support. Check.
Unparalleled German support. Check.
French and German support. Check.
Symbols are more used than numbers. Symbols on the top layer. Check.
EASY diacritics (just look for the dashed circle on the Fn layer). Check.
Non-Germanic language speakers now have a 9 button game pad on the right in 'normal mode'. Check.
FnLock turns on a game mode with the top 2 rows of the keyboard ripe for in-game functions. Check.
With the Pyra you have the opportunity to make a giant leap forward in keyboard design. It really CAN do everything and do it very well. Nothing needs to be kicked to the curb.
There are some very good things going on with this layout:
http://www.keyboard-layout-editor.com/#/layouts/37af15095b2aeedd169b0b5beb3bc9a6
There are also a few things that make it a bit of a train wreck.
No offense intended ED, but it looks like you completely skipped reading the vast majority of the keyboard threads. We all learned a lot. There are a few fundamental things that got skipped. I can provide more lengthy explanations, links, etc upon request on any of the topics. You asked for us to keep this short and I am going to try.
Fn/Meta behavior: The two Fn keys are two different keys with two different needs - but one common behavior. The shoulder Fn needs to create a unique keycode to the OS so that the OS can re-map it to something not Fn-like for games. The keyboard Fn must always perform as Fn. BOTH Fn keys need to behave to the OS as if they were a HARDWARE Fn - i.e. NOT generate just a key code, but instead they must fundamentally change the behavior of the other key pressed. Yes, this can happen at the driver level, but it must happen prior to the OS map.
Fn+Shift is not an option, it is and must be a rule: Every physical key on the keyboard (other than Lshift, Rshift, LFn, RFn, LCtrl, RCtrl, LAlt, RAlt) must have 4 'mappings' or 'layers', even if they are not explicit in the printing on the keys. It is easiest to think of the keyboard as TWO physical keyboards. One is the 'Normal' keyboard where each key has it's unshifted and shifted values. The second keyboard is obtained by pressing Fn. Fn, by it's definition tells the driver, "Switch to the Fn keyboard". The Fn keyboard ALSO has unshifted and shifted values available and should generate codes, whether those are directly mapped to symbols or not. ALL of the keyboard layouts that have F1-F12 keys on the Fn layer do this. Every F1-F12 Fkey MUST be able to be combined as:
Fkey, shift+Fkey, Alt+Fkey, Ctrl+Fkey, Alt+shift+Fkey, Ctrl+Shift+Fkey, Alt+Ctrl+Shift+Fkey, etc...
The fact that shift+Fkey is in that list AND the layouts having F1-F12 on the Fn layer means that Fn+Shift MUST exist.
DosBox, QEMU, X86 compiled Linux programs and "PC Gaming" are all potentially going to be a 'big thing' on the Pyra. Those bring with them a small amount of issues that are MUCH easier to solve now with the keyboard layout than the would be to change later through re-writing and fixing code. They are also another reason why the Fn behavior MUST appear to the OS as if it were a hardware Fn. DosBox and similar go straight to the driver and interpret the keyboard themselves as if it were a US standard layout. They cannot be easily re-mapped in software. What this means is, regardless of what you have mapped to shift+; DosBox will read :. The issue gets more annoying when something is marked that DosBox doesn't understand. Anything you have mapped at a base or Fn layer that isn't a base key will not be read. So, on your layout where Fn+A={ those programs will either do nothing or be confused because there is no { base key on a US keyboard. They'll only see Fn+D=[ IF the Fn is passed as a hard keyboard switch at the driver layer. Many very smart people have tried to 'fix DosBox', none have succeeded. The issue is fundamental in how DosBox reads direct key presses instead of combinations. DosBox is simply the easiest example of this issue, it is not restricted to this one emulator. The whole issue can be cured by, 'Maintaining key pairs from the US keyboard'. This is pretty simple, but DOES require that Fn+Shift be recognized as a 'real thing'.
Fn+Shift is a real thing - and a very handy thing. You will see that the majority of the layouts proposed place Fn and Shift next to each other instead of cross-keyboard on the Pandora. The Pyra has more keys than the Pandora did - and it's a great thing. The fact is, though, it is still short on keys and needs to make use of a second keyboard mapping. So by having Fn and shift next to each other, it becomes possible to chord them. I.e. press both Fn+Shift at the same time as a single press of two keys or 'mashed'. Acknowledging this feature allows the Fn layer's shift modification to be 'opened up'. A hardware-type Fn truly doubles the number of symbols that the Pyra's keyboard can produce. This means that a Fn layer key can produce both upper and lower case letters.
Understanding Fn+Shift gives the Pyra enough keys to map symbols in true US keyboard pairs (DosBox), have the most awesome PC Game controller ever (numbers and F1-F12 on same Fn layer), offer unparalleled international support with simple diacritics all while maintaining unencumbered English usage. It can all be done, but it would require a substantive reconsideration of the current keyboard approach.
http://boards.openpandora.org/topic/16872-and-now-for-something-completely-different-keyboard-option/?p=389806
Ctrl+Insert and Shift+Insert is a real thing. It is part of the CUA standard. It is expected by both Gnome and KDE. https://en.wikipedia.org/wiki/IBM_Common_User_Access
Pause/Break and PrtSc/SysRq should both be top layer keys.
Pause/Break is often used with Ctrl+Pause and Ctrl+Break. Pause then needs to be accessible with Ctrl.
PrtSc is often used in conjunction with Alt. Alt+PtrSc captures the current window (in Gnome, etc) into the copy/paste buffer. PrtSc then needs to be accessible with Alt.
Esc should be accessible, hard to press on accident and present during game play. My preference is on Fn+ top left key above the left nub.
Keyboard and LCD brightness with control for both up and down can be controlled on a single backlight key.
Normal: Screen backlight increase
Shifted: Screen backlight decrease
Fn: Keyboard backlight increase
Fn+shift: Keyboard backlight decrease
All radios AND USB can be controlled on a single IO Control key.
Normal: WiFi toggle
Shifted: Bluetooth toggle
Fn: USB toggle
Fn+shift: 4g toggle
However, a better method might be to have a 'hardware menu button' that pulls up a hardware menu in the OS. By doing it this way, it allows for many more things to be controlled in a central place without any 'button guessing'. On my more recent layouts I designated it on the top left corner above the nubs with the ≡ symbol.
Diacritics and International support:
There are a series of symbols that are commonly used to designate dead key diacritics.
,< .> /? '" `~
These also just happen to conveniently be US keyboard base pairs.
We also, conveniently, have a keyboard that does key, shift+key, Fn+key, Fn+shift+key.
This allows a certain magic to happen.
Normal `~ key is `
Shift+ `~ key is ~
Fn+ `~ key is the ` dead key for grave diacritics.
Fn+shift+ `~ is the ~ dead key for tilde diacritics.
By keeping these symbols as 'base layer', I.e. NOT on the Fn layer, it enables these 'easy diacritics' to happen.
,< .> /? '" `~
Shift+Shift as ShiftLock
Fn+Fn as FnLock
For the most part we can get around not having a dedicated 'CapsLock' key. However, it would be handy to still be able to lock the shifted layer if the user chose to. To solve this, since we have two shift keys, we can have shift+shift = ShiftLock. If the keyboard is in ShiftLock mode, holding shift then pressing a key would generate the unshifted value.
Similarly, we can do the same thing with Fn+Fn = FnLock. This would bring the Fn keyboard layer 'topside' in much the same way as ShiftLock would bring the shifted layer topside. Holding one Fn button when in FnLock mode would produce the UnFn layer value.
Yes, it would be possible to 'lock' both layers at the same time.
Why would German support be limited to the lowercase of Ü, Ö and Ä? They're letters - and they have an upper and a lower case. Yes, their lower case use is more common. But then, whey relegate these to the Fn layer at all? Why not have them on the top layer where they're just as easy to use as the English letters if it can be done without impacting the English keyboard. And while we're at it - lets put them in the same positions that they reside in on the German keyboard. For the longest time I thought this simply couldn't be done. The Pyra just didn't have enough keys to make it happen. I was wrong - it CAN be done and it should be fantastic.
So, PC gaming is going to be a thing on the Pyra. Halflife is already working on the Pandora using the new X86 Linux emulator code. Two of PC gaming's biggest genres are First Person Shooters (FPS) (Halflife type) and role playing games - often online, often massively multiplayer (Neverwinter Nights, WoW). Something these two genres have in common is extensive use of the number keys 12234567890 AND use of F1-F12. Sometimes BOTH are needed during the same game. Often one series or the other is expected to be easily modified with shift+, ctrl+ alt+. For these types of games, it would be a huge advantage to have both the number keys AND the F1-F12 keys be able to be on the same keyboard layer at the same time. I.e. be able to lock in a 'game mode' on the device to have game controls and all of 1-0 and F1-F12 available. Yep, that can be done too.
All of the above CAN be done. Two variations on that theme showing some of the open options:
http://www.keyboard-layout-editor.com/#/layouts/ee8d3bc8b446f99c027105d3810f8d07
http://www.keyboard-layout-editor.com/#/layouts/b76ffdc065642c07243bad385b4a06a8
Fn behavior understood and accounted for. Check.
DosBox and other software that reads keypresses at a driver-layer compliance. Check.
Ctrl+Ins Shift+Ins capable. Check.
Ctrl+Pause/Break capable. Check.
Alt+PrtSc capable. Check.
Screen and keyboard Backlight controls. Check.
Radio and hardware toggles controlled by easy to find 'Hardware Menu' button. Check.
Complete English support. Check.
Unparalleled German support. Check.
French and German support. Check.
Symbols are more used than numbers. Symbols on the top layer. Check.
EASY diacritics (just look for the dashed circle on the Fn layer). Check.
Non-Germanic language speakers now have a 9 button game pad on the right in 'normal mode'. Check.
FnLock turns on a game mode with the top 2 rows of the keyboard ripe for in-game functions. Check.
With the Pyra you have the opportunity to make a giant leap forward in keyboard design. It really CAN do everything and do it very well. Nothing needs to be kicked to the curb.
Last edited by a moderator:
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
Apparently you guys missed it...
This is why the left/right mouse buttons are REVERSED on the left/right nub-clicks.
Left nub moves the mouse.
Right nub pans/scrolls.
Left nub click is right mouse button (pull up menu-properties, etc.) Does not usually 'drag'.
Right nub click is left mouse button (select, drag, etc...)
So, you SELECT by pressing in on the RIGHT nub and drag things around with the LEFT nub.
Click & drag is still there. No problem.
bzar
A Commando
I respect that there's many aspects to this discussion, but I couldn't help chuckling reading this and seeing the extent of your post
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
That WAS the condensed version. Keep in mind, those of us who have been 'working on this' have had more than 6 months of experiment, discoveries, trials, errors and eureka moments that lead up to now. Trying to condense all of that does the whole process an injustice, but we need to drag ED through that process much faster than the rest of us went through it.I respect that there's many aspects to this discussion, but I couldn't help chuckling reading this and seeing the extent of your post
Last edited by a moderator:
- Joined
- Jan 18, 2010
- Messages
- 11,418
No didn't miss it, I understood that was a possible, but not totally confirmed method of handling it. I still see that as a less optimal setup than just having buttons setup for mouse clicking. I'll most likely setup the two auxiliary buttons for mouse clicking.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
I originally wanted to map the mouse buttons to the shoulders - and then was told how wrong I was to even consider such a thing as the nubs were clickable and this was how it would work.
A possible alternative may be to map home/end to the nub clicks and put left and right mouse buttons on the game pad - but that could have issues as well.
True, otherwise the Pyra wouldn't be out for the next 4 years with bazillion posts, and whatever I chose would bring on a bazillion more posts.
That's why the summary thread (sticky) and google docs existed: To offer the results of all that hard work for me to check and choose from what I think would be best.
That's what I completely read. If there was crucial information missing in that summary, I don't know it.
It's as easy as that.
Will most likely not happen, as we like to stick with mainline kernel and as notaz already pointed out, such hardware key is not allowed.
That's why the layout I was working with works WITHOUT a hardware key.
And the reason for that is...?
As far as I can see, everything works fine with Shift and one modifier.
DosBox and QEMU need fixes, yes, that's something we can't change unless we ignore mainline kernel rules again (which I really don't want, as it will be messy to maintain everything otherwise).
It's better to patch DosBox and / or QEMU than the kernel.
Does QEMU even have the issue? AFAIR only DosBox uses the hardware layer of the keys, not QEMU, or does it?
I also wonder whether the DOS layouts can be fixed using a DOS keyboard driver. After all, keyb gr switches to a german keyboard in DosBox as well, maybe we could create a keyb pyra ?
X86 compiled Linux programs usually use SDL, X11 or similar and therefore use the keyboard layout.
At least I haven't seen a game on my Linux laptop that doesn't use my X11 layout, so those won't be an issue.
Which one? Which program except for DosBox does that?
I can understand that. But can you provide a solution that follows the rules of a mainline kernel?
I'd love to have that all fixed, but I'd like to stick with mainline kernel.
Also, I don't want normal users to have a too confusing layout (I also wouldn't like that).
For example:
http://www.keyboard-layout-editor.com/#/layouts/b76ffdc065642c07243bad385b4a06a8
One letter and TWO symbols on ONE key?
Nope, that's overkill.
It's totally missing the number key row, and I can imagine typing a lot of numbers (i.e. in excel) is horrible.
Same for the other ones in the post you linked to. A dedicated number row is, in my opinion, very important.
And is horribly messy for a normal person... having to think about what key combination to press just to change the brightness...
True, but someone would need to code that. Not sure if those on/off buttons are really needed, this is something you can also do from your OS desktop.
Something I (and many other users) probably couldn't remember.
I don't even use ö, ä, ü and ß on the Pandora, as I always forget the key combination.
The keyboard layout shouldn't be too complex, as this is just too confusing and reduces usability A LOT.
Again, no dedicated number keys on both of these layouts. My old Xperia pro had that. I liked the keyboard, but having to press Fn for the buttons made me hate it.
Easy to understand, use and remember: Nope (at least in my opinion).
Yes, but an overkill in the layout that makes things too complex and even makes easy tasks like typing numbers when working with scripts or excel sheets uncomfortable will not be good as well.
FaeMinx
Rainbow Liberation Instigation
*sigh*
If only... If only...
If only... If only...
Saber
Advanced Member
- Joined
- Jan 23, 2012
- Messages
- 1,303
We've already "chastised" ED in a tongue-in-cheek manner for his absenteeism from the drudgery known as the keyboard layouts threads so... unless time machines were invented, we must look to the present and offerThat WAS the condensed version. Keep in mind, those of us who have been 'working on this' have had more than 6 months of experiment, discoveries, trials, errors and eureka moments that lead up to now. Trying to condense all of that does the whole process an injustice, but we need to drag ED through that process much faster than the rest of us went through it.I respect that there's many aspects to this discussion, but I couldn't help chuckling reading this and seeing the extent of your post
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
I don't have a £ symbol, it appears; can you ditch off one of the pointless keys (maybe the Break or ScrollLock)
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Which, as Notaz explained, cannot happen if we're to stick with mainline. It's unfortunate but it's going to have to be a 100% software mod and we'll have to have a modified X server and SDL and hope that's enough.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
That layout doesn't have enough room for all of the needed symbols since it only has 3 logical layers (Normal, Shift, FnShifted (No Fn+Shift layer).
Try this one where real Fn+Shift is allowed:
http://www.keyboard-layout-editor.com/#/layouts/ee8d3bc8b446f99c027105d3810f8d07
Chord Fn+Shift and press V (for value) to generate £.
Fn and press V (for value) to generate €.
The $ is still at shift+4 which, with numbers on the Fn layer and symbol pairs maintained, is done as Fn+shift+R.
If anyone needs a currency symbol other than $, € or £, there is an international currency symbol at Fn+Shift+B so that they can generate the generic currency symbol: ¤
https://en.wikipedia.org/wiki/Currency_sign_(typography)
It works.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
When where did he state/explain this? I must have missed it - sorry.
I'm trying to figure out, though, if Fn isn't really a code-layer-switching 2nd keyboard definition Fn, then how in the world can we have F1-F12 on the Fn layer? Doesn't that make combinations like Shift+F3 impossible?
If it isn't going to interfere with inputting Shift+F6 with F6 on the Fn layer and similar - then how is it going to care that:
Normal N = n
Shifted N = N
Fn N = ñ
Fn+Shift+ N = Ñ
Either all 4 'layers' exist or they don't. Either my n&ñ mapping works or shift+F5 doesn't (and consequently would require F1-F12 on the 'top' layer).
Last edited by a moderator:
FaeMinx
Rainbow Liberation Instigation
Darn it. This device was almost perfect... Now we are stuck with something that will be pretty good in most cases, but frustrating or almost impossible in others. I forsee numerous issues cropping up in the years to come.
I was so looking forward to a 'non-crippled' experience with the Pyra.
The real shame is that the Pyra might last indefinitely...
And here my thoughts are already turning to a successor (which may never come), where we do it right and have a REAL hardware modifier key.
Darn it darn it darn it!
I was so looking forward to a 'non-crippled' experience with the Pyra.
The real shame is that the Pyra might last indefinitely...
And here my thoughts are already turning to a successor (which may never come), where we do it right and have a REAL hardware modifier key.
Darn it darn it darn it!
Similar threads
- Poll
