Replies: 1 comment
-
The AltGr key is not mapped by EPKL. This is because it's a tricky key, as you've noticed. Therefore, what's bothering you is not solvable by "unmapping" AltGr as it was never mapped in the first place. You don't want to unmap it as you describe, as AltGr is a combination of LCtrl+RAlt which EPKL doesn't touch; my program only reads its state when called for. So no wonder that attempt did you no good. If unmapping other keys that way doesn't work for you, that's worse. You're using one of the very latest commits, I hope? Because if you didn't compile from a new commit it won't know what to do with the Unmapped syntax. Edit: Just tested |
Beta Was this translation helpful? Give feedback.
-
eD layouts don't work very well with certain apps. A nice solution is to use VK or System layout.
Unfortunately, layouts that are not eD are prone to having their LCtrl get stuck when typing at high speeds using AltGR. Because of this you are forced to install a custom MSKLC layout and use SuspendingApps.
Of course some apps, games and websites such as MonkeyType don't need that level of complexity, but one simply cannot live without Extend!
I understand that AltGR is necessary for using the other Extend Layers, but I could suggest a workaround involving unmapping AltGR (unmap LCtrl and Right Alt?) key or treating as Windows does naturally so that we can use the first layer of extend which is most of the time enough for most apps that are uncompatible with eD states?
Could the property
QWRCT = Unmapped
work? I tried to do that but then the key becomes unusable. But I am sure I am doing something wrong because the same thing will happen if I do something likeQW_D = Unmapped
.I am using an underlying Colemak CAWS ISO.
Beta Was this translation helpful? Give feedback.
All reactions