diff options
author | Campbell Barton <ideasman42@gmail.com> | 2016-04-06 02:30:20 +0300 |
---|---|---|
committer | Campbell Barton <ideasman42@gmail.com> | 2016-04-06 02:30:20 +0300 |
commit | f5fb4361d20f5e7b34866262541eaa1e5319e57f (patch) | |
tree | 8f725c56209187239423d62e877bf1a2364d2ec1 /intern/ghost | |
parent | cc970dc08a7a03594728fb0ecfbdb72689a452f3 (diff) |
Cleanup: indentation
Diffstat (limited to 'intern/ghost')
-rw-r--r-- | intern/ghost/intern/GHOST_SystemX11.cpp | 62 |
1 files changed, 31 insertions, 31 deletions
diff --git a/intern/ghost/intern/GHOST_SystemX11.cpp b/intern/ghost/intern/GHOST_SystemX11.cpp index beb8ab5db85..3e1dbd18119 100644 --- a/intern/ghost/intern/GHOST_SystemX11.cpp +++ b/intern/ghost/intern/GHOST_SystemX11.cpp @@ -787,40 +787,40 @@ GHOST_SystemX11::processEvent(XEvent *xe) GHOST_TKey gkey; #ifdef USE_NON_LATIN_KB_WORKAROUND - /* XXX Code below is kinda awfully convoluted... Issues are: - * - * - In keyboards like latin ones, numbers need a 'Shift' to be accessed but key_sym - * is unmodified (or anyone swapping the keys with xmodmap). - * - * - XLookupKeysym seems to always use first defined keymap (see T47228), which generates - * keycodes unusable by convertXKey for non-latin-compatible keymaps. - * - * To address this, we: - * - * - Try to get a 'number' key_sym using XLookupKeysym (with or without shift modifier). - * - Fallback to XLookupString to get a key_sym from active user-defined keymap. - * - * Note that this enforces users to use an ascii-compatible keymap with Blender - but at least it gives - * predictable and consistent results. - * - * Also, note that nothing in XLib sources [1] makes it obvious why those two functions give different - * key_sym results... - * - * [1] http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/KeyBind.c - */ - if ((xke->keycode >= 10 && xke->keycode < 20)) { - key_sym = XLookupKeysym(xke, ShiftMask); - if (!((key_sym >= XK_0) && (key_sym <= XK_9))) { + /* XXX Code below is kinda awfully convoluted... Issues are: + * + * - In keyboards like latin ones, numbers need a 'Shift' to be accessed but key_sym + * is unmodified (or anyone swapping the keys with xmodmap). + * + * - XLookupKeysym seems to always use first defined keymap (see T47228), which generates + * keycodes unusable by convertXKey for non-latin-compatible keymaps. + * + * To address this, we: + * + * - Try to get a 'number' key_sym using XLookupKeysym (with or without shift modifier). + * - Fallback to XLookupString to get a key_sym from active user-defined keymap. + * + * Note that this enforces users to use an ascii-compatible keymap with Blender - but at least it gives + * predictable and consistent results. + * + * Also, note that nothing in XLib sources [1] makes it obvious why those two functions give different + * key_sym results... + * + * [1] http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/KeyBind.c + */ + if ((xke->keycode >= 10 && xke->keycode < 20)) { + key_sym = XLookupKeysym(xke, ShiftMask); + if (!((key_sym >= XK_0) && (key_sym <= XK_9))) { key_sym = XLookupKeysym(xke, 0); - } - } + } + } else { key_sym = XLookupKeysym(xke, 0); } - if (!XLookupString(xke, &ascii, 1, &key_sym_str, NULL)) { - ascii = '\0'; - } + if (!XLookupString(xke, &ascii, 1, &key_sym_str, NULL)) { + ascii = '\0'; + } if ((gkey = convertXKey(key_sym)) == GHOST_kKeyUnknown) { gkey = convertXKey(key_sym_str); @@ -1385,8 +1385,8 @@ GHOST_TSuccess GHOST_SystemX11:: setCursorPosition( GHOST_TInt32 x, - GHOST_TInt32 y - ) { + GHOST_TInt32 y) +{ /* This is a brute force move in screen coordinates * XWarpPointer does relative moves so first determine the |