-
-
Notifications
You must be signed in to change notification settings - Fork 22k
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 incorrect KEY_MODIFIER_MASK
value
#98441
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR changes the API which requires additional steps. You can find relevant information in the docs:
https://docs.godotengine.org/en/latest/contributing/development/handling_compatibility_breakages.html
core/os/keyboard.h
Outdated
@@ -249,7 +249,7 @@ enum class Key { | |||
|
|||
enum class KeyModifierMask { | |||
CODE_MASK = ((1 << 23) - 1), ///< Apply this mask to any keycode to remove modifiers. | |||
MODIFIER_MASK = (0x7F << 22), ///< Apply this mask to isolate modifiers. | |||
MODIFIER_MASK = (0x7E << 22), ///< Apply this mask to isolate modifiers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MODIFIER_MASK = (0x7E << 22), ///< Apply this mask to isolate modifiers. | |
MODIFIER_MASK = (0x1FF << 23), ///< Apply this mask to isolate modifiers. |
Currently the upper 9 bits are reserved for modifiers (see #98447).
If we want to break API compatibility with this change (which I believe, we should in order to fix this API-bug), then we should include the complete range of valid modifiers, so that we don't need to change it again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently the upper 9 bits are reserved for modifiers
Not sure if KPAD
and GROUP_SWITCH
should be considered modifiers.
But both seems to be unused:
GROUP_SWITCH
flag seems to be completely unused (I have no idea what it was intended for).KPAD
flag is parsed by macOS native menu code, but it must an oversight, since it's never set by any code.
I would probably mask it like this:
0-20 Unicode value |1|
21 Reserved |1| CODE_MASK
22 Special key flag |1|
23 Reserved |2| Keep reserved in case we want to add some other special flag.
24 CTRL or CMD flag |3|
25 SHIFT flag |3|
26 ALT flag |3|
27 META flag |3| MODIFIER_MASK
28 CTRL flag |3|
29 (KPAD) Reserved |3|
30 (GROUP_SWITCH) Reserved |3|
31 Reserved |4| Sign bit, keep clean to avoid negative values if it's used with int32_t API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, so that would boil down to:
MODIFIER_MASK = (0x7E << 22), ///< Apply this mask to isolate modifiers. | |
MODIFIER_MASK = (0x7F << 24), ///< Apply this mask to isolate modifiers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Yelloween10 Please see the above suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Yelloween10 Please see the above suggestion.
I was just working on it at the moment. I was busy for a few weeks, I have time to do it now.
I read the docs and I'm confused about how I should continue in this situation. How should I approach this? |
you need to add expected changes to API in the correct basically you add
you should find the expected validation error in the failed check that has been run on your PR (this one), |
3c6f926
to
7c88dcb
Compare
KEY_MODIFIER_MASK
value
Is there anything I should do? |
You've added unrelated changes to the api-validation files, you need to resolve that conflict |
I noticed that the changes I made eventually ended up getting conflicts because of the new changes. I tried adding my original change at the end again, but it still says that there are conflicts. |
-------- | ||
Validate extension JSON: Error: Field 'classes/TranslationServer/methods/standardize_locale/arguments': size changed value in new API, from 1 to 2. | ||
|
||
Optional argument added. Compatibility method registered. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've added a lot here that I'm not sure where it comes from, did you copy these over from the 4.2 file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I copied the lines from 4.3-stable.expected
and put my changes at the end. I thought that it would fix the message "This branch has conflicts that must be resolved". I did that because my changes got outdated from the new lines inside of the 4.3-stable.expected
file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to rebase your branch as you are behind and you are making these changes on top of older code, you shouldn't copy what's in these files right now but rebase instead and just add your content
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can I do that exactly? The last time I tried it, I ended up accidentally ruining the entire PR. Sorry about the questions, I'm nervous about that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the interactive rebase for details
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, so I need to update my branch with a rebase?
I have another question, should I squash my commits after I'm done?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes you need to rebase your branch on the up-to-date branch, squashing would be good too but not necessary until this is approved
526dba2
to
94a5b52
Compare
Is this good? |
94a5b52
to
44419cb
Compare
Compatibility code is correct now! |
Should I squash it now? |
You can do it now if you like, but you don't have to untill it's approved |
Updated key modifier mask and documented API change Changed the old value Changed the old value inside the .expected file Resolved Conflicts Moved changes to the end
44419cb
to
0153cb8
Compare
Alright, thank you. |
When would it be available to review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes make sense as discussed here: #98441 (comment)
I can't predict how many problems this breaking change causes for projects. But since the previous implementation is simply wrong, i'm in favor of merging.
Thanks! |
This pull request fixes an incorrect value assignment for
MODIFIER_MASK
in keyboard.h and @GlobalScope.xml.MODIFIER_MASK
to0x7E << 22
to isolate modifier keys correctly, ensuring that it does not interfere with theKey.SPECIAL
value.I tested the solution by checking that the result of the
AND
operation betweenMODIFIER_MASK
andCODE_MASK
returned0
, confirming that the modifier mask is now correctly configured.(Sorry for the confusion with the previous PR; I'm new to this and accidentally included others' changes, so I created this new one for clarity.)
Fixes #89775