cefpython
cefpython copied to clipboard
cztomczak
Create unified key mappings for all platforms
Currently in examples key presses that are handled in
KeyboardHandler.OnKeyEvent, are checked against raw integer values to check for
key code. The code for Linux and Windows is as follows:
# F5
if (linux and event["native_key_code"] == 71) \
or (windows and event["windows_key_code"] == 116):
print("[wxpython.py] F5 pressed, calling"
" browser.ReloadIgnoreCache()")
browser.ReloadIgnoreCache()
return True
# Escape
if (linux and event["native_key_code"] == 9) \
or (windows and event["windows_key_code"] == 27):
print("[wxpython.py] Esc pressed, calling browser.StopLoad()")
browser.StopLoad()
return True
# F12
if (linux and event["native_key_code"] == 96) \
or (windows and event["windows_key_code"] == 123):
print("[wxpython.py] F12 pressed, calling"
" browser.ShowDevTools()")
browser.ShowDevTools()
return True
The code for Mac is as follows:
# Cmd+Opt+I
if event["modifiers"] == 136 and event["character"] == 94:
browser.ShowDevTools()
return True
# F5
if event["modifiers"] == 0 and event["character"] == 63240:
browser.ReloadIgnoreCache()
return True
# Esc
if event["modifiers"] == 0 and event["character"] == 27:
browser.StopLoad()
Actually in this case "123" key code could be replaced with cefpython.VK_F12 on
Windows. Virtual key codes are provided only for Windows, see the VirtualKey
wiki page. We should provide similar key codes using VK_ constants for other
platforms: Mac, Linux.
On Mac and Linux some key codes are similar (Esc), but others like F5 are
different.
In the kivy_.py example there is a mapping of Linux keys that could be used to
translate Windows VK key codes to Linux ones. See the translate_to_cef_keycode
function:
https://code.google.com/p/cefpython/source/browse/cefpython/cef3/linux/binaries_
64bit/kivy_.py?r=ad99514963ae#355
In the code pasted above, you can see that on all platforms a different
event[key] is being checked:
* On Windows it is event["windows_key_code"]
* On Linux it is event["native_key_code"]
* On Mac it is event["character"]
I think we should add event["virtual_key"] to simplify things. This virtual_key
would be checked against cefpython.VK_ constants.
Maybe we should also export all VK_ to a dict? And make it accessible through
cefpython.virtual_keys? I think this could be useful, for example:
{
"a": 65,
"b": 66,
...
}
Original issue reported on code.google.com by [email protected] on 21 Jan 2015 at 9:04
Attaching log info when pressing F5 or 'a' for all platforms.
For VKEY_ codes for Linux/Mac see keyboard_codes_posix.h in
Chromium/src/ui/events/keycodes/:
https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/keycodes/keyboard_codes_posix.h
For VKEY_ codes for Windows see keyboard_codes_win.h:
https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/keycodes/keyboard_codes_win.h
Original comment by [email protected] on 23 Jan 2015 at 5:26
Attachments:
Summary for the log files attached in previous comment:
* F5 has 2 calls to OnPreKeyEvent and OnKeyEvent on all platforms with types: KEYEVENT_RAWKEYDOWN and KEYEVENT_KEYUP.
* 'a' on Linux generates 1 call to OnPreKeyEvent and 1 call to OnKeyEvent with type: KEYEVENT_KEYUP.
* 'a' on Mac generates 2 calls to OnPreKeyEvent and 2 calls to OnKeyEvent with types: KEYEVENT_RAWKEYDOWN and KEYEVENT_KEYUP
* 'a' on Windows generates:
* 2x OnPreKeyEvent with types: KEYEVENT_RAWKEYDOWN and KEYEVENT_CHAR (modifiers 0 and 512)
* Next 2x OnKeyEvent with types: KEYEVENT_RAWKEYDOWN and KEYEVENT_CHAR (modifiers 0 and 512)
* Next OnPreKeyEvent and OnKeyEvent with type: KEYEVENT_KEYUP (modifiers 0)
* Next OnPreKeyEvent and OnKeyEvent with type: KEYEVENT_RAWKEYDOWN (modifiers 8)
The 'type' can be one of:
KEYEVENT_RAWKEYDOWN = 0,
KEYEVENT_KEYDOWN = 1,
KEYEVENT_KEYUP = 2,
KEYEVENT_CHAR = 3
Original comment by [email protected] on 23 Jan 2015 at 5:40
See also CEF unittests/os_rendering_unittest.cc > OSR_TEST_KEY_EVENTS:
https://code.google.com/p/chromiumembedded/source/browse/trunk/cef3/tests/unittests/os_rendering_unittest.cc?r=r1987#548
Original comment by [email protected] on 23 Jan 2015 at 5:43