Fix gtk key repeat logic #1081
Fix gtk key repeat logic #1081
Conversation
|
For more context on the logic for modifiers: Mozilla doesn't use gdk for this, but reaches through and calls xkb_keymap_mod_get_index to map the modifiers (see I also have a comment in there about using Keymap as a more principled way of getting the numlock state. Oddly, Mozilla does this for nsBidiKeyboard.cpp, but not for numlock. Maybe somebody who knows this better than me can shed some light. In the meantime, I'm pretty satisfied that the logic in this PR is good enough, and doing something else might cause more problems. |
|
Also, Mozilla's logic is a bit different. Instead of having a hashmap, they have a "last key pressed" (which is a hardware keycode), but don't clear it on keyup if the value doesn't match. I also confirm that Mozilla works here. I think maybe that logic might be a touch more robust, as it's less likely that a key will be stuck in the down position on something like focus change. |
Use single optional keycode rather than hashset as it's more robust against a key getting "stuck" due to focus or whatnot.
|
I can confirm that it fixes #1080. |
| // Note: this is the usual value on X11, not sure how consistent it is. | ||
| // Possibly we should use `Keymap::get_num_lock_state()` instead. | ||
| (ModifierType::MOD2_MASK, Modifiers::NUM_LOCK), |
There was a problem hiding this comment.
I tested this on Wayland and I'm getting MOD2_MASK as well.
CHANGELOG.md
Outdated
| @@ -15,6 +15,7 @@ You can find its changes [documented below](#060---2020-06-01). | |||
| - `Scale::from_scale` to `Scale::new`, and `Scale` methods `scale_x` / `scale_y` to `x` / `y`. ([#1042] by [@xStrom]) | |||
| - Major rework of keyboard event handling ([#1049] by [@raphlinus]) | |||
| - `Container::rounded` takes `KeyOrValue<f64>` instead of `f64`. ([#1054] by [@binomial0]) | |||
| - Fix Gtk key repeat logic ([#1081] by [@raphlinus]) | |||
There was a problem hiding this comment.
This should go into the Fixed section.
- GTK: Don't interrupt `KeyEvent.repeat` when releasing another key. ([#1081] by [@raphlinus])There was a problem hiding this comment.
@raphlinus Did you miss my suggestion for the changlog entry or did you not like it?
There was a problem hiding this comment.
Sorry, I missed it, I only caught the part about it being in the wrong section. That's what I get for trying to do this stuff before I've had my coffee.
Keep track of which keys are pressed and use that to determine whether
a key is a repeat. The previous logic of comparing the keyval to the
last value fails in the case of multiple keys.
Also add lock modifiers, a followup from #1079.
Fixes #1080