Allow mapping special keys #1928
Conversation
|
You cant use strings from UCKeyTranslate to convert keys to key codes. You have no idea how to convert those strings back into key codes. Also since keyDown already calls UCKeyTranslate do we really need to call it again? And is we do why cant we use _glfw.ns.unicodeData? |
Can't we just use something like NSNumber* charToKeyCode(NSString *keyChar)
{
static NSMutableDictionary* dict = nil;
if (dict == nil) {
dict = [NSMutableDictionary dictionary];
// For every keyCode
for (CGKeyCode i = 0; i < 128; i++) {
NSString* str = keyCodeToString(i);
if (str != nil && ![str isEqualToString:@""]) {
[dict setObject:[NSNumber numberWithInt:i] forKey:str];
}
}
}
return [dict objectForKey:keyChar];
}to build a reverse mapping?
We most likely don't need to call it again, I just wanted to be somewhat confident that this idea is even possible before doing any kind of optimisation. |
|
I dont think I understand, wont that just end up mapping the special |
|
It shouldn't since the reverse mapping function uses |
|
keyCodeToString() will map 0x29 to odiaresis and so the reverse map will The way key mapping works is that when the key event reaches kitty, if So what you would need to do is detect when keyCodeToString() is mapping Basically, this is a bug in Apple's API. They should not have reused key |
Luflosi
force-pushed
the
keyboard_improvement
branch
from
7a0a67e
to
a8c355d
Compare
|
I implemented something that I thought would work but it doesn't yet. I tried adding new |
|
There is a bunch of stuff to do when adding a new key, check the previous commits for adding the plus key for example. |
|
No there is no way to use anythin other than a numeric constant in a switch statement. You can make it symbolic with a #define if you like. |
|
What do the constants in |
|
They are used to handle the kitty extended keyboard protocol |
|
How can I figure out what to map ä, ö, ü and ß to? |
|
You dont need to figure it out, just run update_encoding() it will |
|
Why does |
|
It contains both, since there is no reason not too and who knows what |
Luflosi
force-pushed
the
keyboard_improvement
branch
2 times, most recently
from
2698351
to
5dbf40c
Compare
|
It's quite painful to add new keys tbh. |
|
18000 lines changed in |
|
If I add dead keys, they won't work as keyboard shortcuts, right? |
|
Whether a key is a dead key or not depends on the currently active |
Luflosi
force-pushed
the
keyboard_improvement
branch
2 times, most recently
from
57873dc
to
5af371b
Compare
|
Do you know what the test error message means? |
|
It means interpret_key_evet() is not giving an expected results for the |
|
What do the |
|
they are used to interpret what alt+shift+key should become in the |
|
When you added |
|
SHIFTED_PRINTABLE is a superset of UNSHIFTED_PRINTABLE, it start as a |
|
Yeah but that means, that |
|
yes |
Luflosi
force-pushed
the
keyboard_improvement
branch
2 times, most recently
from
394c6b8
to
2cfdc25
Compare
b3b830b did not actually make `update_encoding()` filter `GLFW_KEY_LAST_PRINTABLE` because `name` contained the key name after applying `symbolic_name()`, which replaces underscores with spaces. Instead of replacing the underscore in `LAST_PRINTABLE` with a space, I moved the check above the call to `symbolic_name()`. This is more readable and future-proof in my opinion.
Luflosi
force-pushed
the
keyboard_improvement
branch
from
2cfdc25
to
f3be5b5
Compare
|
After rebasing onto the latest master, I got the following traceback when regenerating the automatically generated files: Do you know why this happens? What is the purpose of the |
|
g is the module globals, it contains all the key names defined at global |
|
Do you know why the exception happens? What can I do to fix it? Do I somehow need to add the keys to |
|
If you have added them to ENCODING they will be automatically added to g |
|
Well, I'm trying to add the new keys to diff --git a/kitty/key_encoding.py b/kitty/key_encoding.py
index 2e2ab6e4..63ca87c2 100644
--- a/kitty/key_encoding.py
+++ b/kitty/key_encoding.py
@@ -352,12 +352,10 @@ for key_name, enc in ENCODING.items():
key_name = key_name.replace(' ', '_')
g[key_name] = config_key_map[key_name] = key_name
key_rmap[enc] = key_name
config_key_map.update({
- k: g[v] for k, v in key_name_aliases.items()
+ k: v for k, v in key_name_aliases.items()
})
-enter_key = KeyEvent(PRESS, 0, g['ENTER'])
-backspace_key = KeyEvent(PRESS, 0, g['BACKSPACE'])
+enter_key = KeyEvent(PRESS, 0, 'ENTER')
+backspace_key = KeyEvent(PRESS, 0, 'BACKSPACE')
del key_name, enc, geverything seems to work fine. |
|
Running the two functions now obviously works because the keys are already in |
|
Of course it works. You simply have to run update_encoding() before adding |
|
Thanks for 41b0f88. It works as expected. |
`glfwGetCocoaKeyEquivalent()` in `glfw/cocoa_window.m` expects the returned characters to be of type `unichar`, which won't work for all unicode characters because it is defined as `unsigned short` according to https://developer.apple.com/documentation/foundation/unichar?language=objc, which is only guaranteed to be at least 16 bits in size. The code calling this function also expects the encoding to be UTF-16. When I added the various keys in kovidgoyal#1928, I missed these facts. This means, that `glfwGetCocoaKeyEquivalent()` will behave unexpectedly when called with any of the new-ish keys. Luckily this function is currently only used for determining the macOS shortcut for `new_os_window` but I plan on using it more in the future. Some of the constants, e.g. `NSBackspaceCharacter` are UTF-16 constants, so we can't just use UTF-8 everywhere. I fixed the problem by using either UTF-8 characters packed into a `uint32_t` or UTF-16 characters in a `unichar` and then converting them to a UTF-8 encoded char string. `NSEventModifierFlagNumericPad` isn't guaranteed to fit in a `unichar`, which made this undefined behaviour. It also didn't work. I tried to make it work using `NSEventModifierFlagNumericPad` as a modifier instead, as can be seen in this commit, but couldn't get it to work either because the constants used are native key codes and not unicode characters. Therefore the numpad keys will be removed in the next commit.
`glfwGetCocoaKeyEquivalent()` in `glfw/cocoa_window.m` expects the returned characters to be of type `unichar`, which won't work for all unicode characters because it is defined as `unsigned short` according to https://developer.apple.com/documentation/foundation/unichar?language=objc, which is only guaranteed to be at least 16 bits in size. The code calling this function also expects the encoding to be UTF-16. When I added the various keys in kovidgoyal#1928, I missed these facts. This means, that `glfwGetCocoaKeyEquivalent()` will behave unexpectedly when called with any of the new-ish keys. Luckily this function is currently only used for determining the macOS shortcut for `new_os_window` but I plan on using it more in the future. Some of the constants, e.g. `NSBackspaceCharacter` are UTF-16 constants, so we can't just use UTF-8 everywhere. I fixed the problem by using either UTF-8 characters packed into a `uint32_t` or UTF-16 characters in a `unichar` and then converting them to a UTF-8 encoded char string. `NSEventModifierFlagNumericPad` isn't guaranteed to fit in a `unichar`, which made this undefined behaviour. It also didn't work. I tried to make it work using `NSEventModifierFlagNumericPad` as a modifier instead, as can be seen in this commit, but couldn't get it to work either because the constants used are native key codes and not unicode characters. Therefore the numpad keys will be removed in the next commit.
Closes #1919.
The function is from https://stackoverflow.com/questions/8263618/convert-virtual-key-code-to-unicode-string.
keyCodeToString()translates a key code to an NSString. It would be nice to completely replacetranslateKey()so that we don't need to use a hardcoded mapping anymore but I don't think that's possible because for example pressing any function key results in a String with the UTF-8 representation having a value of 16 in the first and only byte. This does not allow distinguishing between those keys so we need to come up with another solution, possibly combiningkeyCodeToString()andtranslateKey().