-
-
Notifications
You must be signed in to change notification settings - Fork 977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix macOS keyboard shortcut encoding #2224
Fix macOS keyboard shortcut encoding #2224
Conversation
I'm not sure I follow. If some of the constants are UTF-16 strings, why unsigned short[16] cocoa_key for the key? Or if you want to return them as UTF-8 which is a better char[64] cocoa_key The calling function can provide the array for it. So you dont have to |
Shouldn't two |
Depends on what size the keynames can reach, with these sorts of things |
Ok, I will use UTF-8 then. But the length of the key names shouldn't matter, right? We are only returning a single Unicode character. |
At the moment its only a single unicode character, who knows if that |
6bdc2f9
to
8f5c30d
Compare
`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.
8f5c30d
to
1a368bc
Compare
See previous commit message for the reason.
1a368bc
to
3842350
Compare
Please review. |
Why is making |
In general it is always better to avoid library functions allocating their own |
Please don't merge this yet. I need to do some cleanup and want to get some feedback first.
glfwGetCocoaKeyEquivalent()
inglfw/cocoa_window.m
expects the returned characters to be of typeunichar
, which won't work for all unicode characters because it is defined asunsigned 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 #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 fornew_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 aunichar
and then converting them to anNSString
.I removed the numpad keys because
NSEventModifierFlagNumericPad
isn't guaranteed to fit in aunichar
, which makes this undefined behaviour. It also didn't work. I tried usingNSEventModifierFlagNumericPad
as a modifier instead, as can be seen in the first commit, but couldn't get it to work either because the constants used are native key codes and not unicode characters.Is it ok to pass the
NSString
using a void pointer? Also please check if the memory forNSString
is properly handled and not freed prematurely. I may need aretain
or something but I still don't understand Objective-C memory management enough.