D6233: KKeyServer: fix handling of KeypadModifier.

David Faure noreply at phabricator.kde.org
Sun Jun 18 15:30:03 UTC 2017


dfaure added inline comments.

INLINE COMMENTS

> graesslin wrote in kkeyserver.cpp:976-980
> This is a special handling from KGlobalAccel. Are you sure it belongs into the generic implementation?

I would say yes, because e.g. Ctrl+& (on qwerty) is going to include Shift no matter which application is calling this method, and it should be removed (just like Qt does when recording "Ctrl+&" rather than "Ctrl+Shift+&" or "Ctrl+Shift+7".

But anyway in practice the only other caller of this method is kwin, and it only cares for [Ctrl|Alt|None]+[Left|Right|Up|Down|Space|Return|Escape], if I read the code correctly.

See https://lxr.kde.org/ident?_i=xcbKeyPressEventToQt&_remember=1
and AbstractClient::keyPressEvent in kwin.

So, while technically this code could stay in kglobalaccel, it still seems more correct to me to have it here in the generic "xcb key event to keyQt conversion" code (and this avoids calling xcb_key_symbols_alloc again in kglobalaccel).

> graesslin wrote in kkeyserver_x11.h:161
> xkb has the modifier mask defined as uint32_t:
> 
> typedef uint32_t xkb_mod_mask_t

strange, I see this:

typedef struct xcb_key_press_event_t {
[...]

  uint16_t        state; /**<  */

[...]

and `grep modifiers /usr/include/xcb/xproto.h| grep uint` shows consistent use of uint16_t.

xkb_mod_mask_t seems to come from xcbcommon which is unrelated to the APIs used here, right?

REPOSITORY
  R278 KWindowSystem

REVISION DETAIL
  https://phabricator.kde.org/D6233

To: dfaure, graesslin
Cc: graesslin, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170618/f241944f/attachment.html>


More information about the Kde-frameworks-devel mailing list