[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [m17n-list] Modifier Keys for fcitx-m17n?
From: |
handa |
Subject: |
Re: [m17n-list] Modifier Keys for fcitx-m17n? |
Date: |
Thu, 23 Nov 2017 11:21:38 +0900 |
In article <address@hidden>, Richard Wordingham <address@hidden> writes:
> > It seems that fctix-m17n is innocent. The culprits seems to be higher
> > up in fcitx.
> The culprits in fcitx are indeed ximhandler.c (for X) and ipc.c (for
> GTK, e.g. LibreOffice) in Fcitx Version 4.2.9.1. The most obvious
> correction is defeated by the utility routine FcitxHotkeyGetKey(), which
> looks as though it would case grief for case sensitivity with super and
> hyper. (None of the input methods in the main M17n database uses these
> two modifiers.)
> The fix that works for AltGr bound to mod5 is to insert the following
> line immediately before the call of FcitxInstanceProcessKey():
> state |= originstate & FcitxKeyState_ScrollLock;
> The corresponding sharable objects on Ubuntu (at least, on
> Xenial 16.04) are fcitx-xim.so and fcitx-ipc.so.
> The binding works by the AltGr key being declared to have keysym
> ISO_Level3_Shift, and then keysyms ISO_Level3_Shift and Mode_Switch
> being bound to modifier mod5.
Thank you for debugging this problem. But, if the problem is
in fcitx, please suggest your solution to the developpers of fcitx.
> Are there environments where an M17n input method should duplicate a
> mapping for, for instance, G-i, with the same mapping for A-i?
What do you mean by "duplicate"? When an M17n input method contains a
rule for A-i, that rule should be fired even if a user types G-i? Then,
no. I think there's no such a situation.
---
K. Handa
address@hidden