https://bugs.kde.org/show_bug.cgi?id=464735

--- Comment #10 from Bernd Steinhauser <li...@bernd-steinhauser.de> ---
I recently noticed that a change with commit id
1240ac1dfe4569f3bb5d5d182ae3c393dc2c5bd5 to buttonrebindsfilter was made due to
bug 484367. This introduces processing of symbols from level1 and level2 of the
layout.

The problem described in this bug still persists however, since for the Neo
layout (which I am using), keys on level4 (Page Up/Down) can match. FYI, the
modifier definition is as such:
    include "shift(both_capslock)"
    include "level3(caps_switch)"
    include "level3(bksl_switch)"
    include "level5(lsgt_switch_lock)"
    include "level5(ralt_switch_lock)"

(Note that I am not sure if the corresponding levels would then be level == 3
and level == 5. Might be 2 and 4 instead, but I'm unsure. :()
I think, there are two options to deal with that:
Option 1:
in ButtonRebindsFilter::sendKeySequence, do not only check for level 1, but
handle higher levels as well. Currently it only checks for level == 1 and
ignores the rest:
    if (key & Qt::ShiftModifier || level == 1) {
        sendKey(KEY_LEFTSHIFT);
    }

The problem with that is that, afaics, input-event-codes.h does not define a
specific key associated with higher level modifiers. From a quick search, I
also couldn't find definitions for those in Qt. So one would need to get them
from xkb, if that is possible?

Option 2:
Basically the patch I posted above. It restricts the search to 2 levels. This
works for me, but in some corner cases, where people try to set a button rebind
accessing a symbol on level3, e.g. in the german layout AltGr + 7, which is {,
would not be found. However, this would also be the case with the current code,
as AltGr (=KEY_RIGHTALT) is not handled either. If that is an acceptable
limitation, then the patch would be fine, I think.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to