More accurate handling of unicode/numpad input in gtk3 backends. #17791
Conversation
0ef1c4a to
28f9312
Compare
|
Interesting; some time back I tried to replace those magic numbers with GDK keysyms, but found that the numpad appeared to work backwards of numlock. I wonder if this will work correctly here. |
|
It works correctly locally (the numbers were just wrong in keyvald for numpad...), but CI seems unhappy... |
baf3410 to
72f731f
Compare
|
CI doesn't like your test, it seems. |
|
I know :/ |
af82f01 to
11e3ba8
Compare
|
This fixes input via numpad for me. |
12f2543 to
d9343e1
Compare
|
I decided to just skip the gtk test on travis for now... |
| # This is not actually really the right API: it depends on the | ||
| # actual keymap (e.g. on Azerty, shift+agrave -> 0). | ||
| Gtk.test_widget_send_key(fig.canvas, key, mod) |
There was a problem hiding this comment.
Could this be why it's getting stuck? Maybe you can check len(buf) and assert the result after shutting down?
There was a problem hiding this comment.
Actually turns out that even locally this is not passing anymore, i.e. calls to Gtk.test_widget_send_event (or Gdk.simulate_key_event) don't result in the key_press_event handler being called at all. At some point it worked, so likely a Gtk version thing? I just xfailed the whole thing for now...
There was a problem hiding this comment.
According to https://mail.gnome.org/archives/commits-list/2017-January/msg01173.html, those were never fully implemented (I only see an x11 version in that commit).
4acfd3b to
7349d3e
Compare
|
rebased |
See changelog.
PR Summary
PR Checklist