fcitx breaks X11 compose

[Gunnar Hjalmarsson]

In order to meet the expectations by Brazilian Portuguese users (see bug #518056), the libx11-data package provides the file /usr/share/X11/locale/pt_BR.UTF-8/Compose. So if LC_CTYPE is set to "pt_BR.UTF-8", either explicitly or inherited from LANG, typing '+c results in the ç character. This works when the IM framework is IBus or none (the latter is really xim), but if you switch to fcitx, it fails, i.e. '+c' gives ć.

This makes me fear that fcitx somehow breaks X11 compose. Considering that there is a discussion about making fcitx the default IM framework for all users in 15.10, I think this a matter of high priority.

[Aron Xu (happyaron)]

I haven't had time to verify the status yet, but there is a bit difference on keyboard handling in current fcitx package.

When using ibus, we were using X to handle keyboard layouts directly, and use ibus for holding those engines only. With current fcitx configuration, keyboard layouts (xkb) configurations are processed by fcitx before X. This is still enabled in Vivid because I want to give it more room for fixing the race incompatibilities, but we can disable it if we are really making it default for everyone but the keyboard stuff isn't worked out properly. That would mean doing the same like ibus - using X to process keyboard layouts directly.

Rationale on why we need IM framework processing the keyboard stuff is that this gives portability among different display server technologies, and more importantly, users will get the same experience when moving among them using the same configuration, without being bothered by races of different display servers (X, Wayland, Mir and maybe more).

[csslayer (wengxt)]

It's easy to fix actually. There was a new library I planned to add in new fcitx. But after some time passed, I found that xkbcommon added same functionality. So I could directly use xkbcommon to implement this.

xkbcommon support is added in git of fcitx and fcitx-qt5.

[Gunnar Hjalmarsson (gunnarhj)]

@csslayer: Sounds promising indeed. :)

[Gunnar Hjalmarsson (gunnarhj)]

Trying to understand this a little better. Right now I think I didn't describe it correctly in the bug description above.

To me it looks like IBus totally overrides the functionality provided by libx11.

http://manpages.ubuntu.com/manpages/trusty/man5/Compose.5.html

The reason, why '+c = ç under the pt_BR.UTF-8 locale when IBus is enabled, seems to be that some of the X11 compose rules have been hardcoded in the IBus source code. So far so good, but if you want to customize the behavior with e.g. a ~/.XCompose file, you need to disable IBus.

Tried with uim. Unlike IBus, uim seems to truly honor X11 compose. ~/.XCompose works under uim.

So, since this bug was filed as a fcitx ditto: Would the use of xkbcommon result in fcitx honoring X11 compose in the same manner as e.g. uim?

[csslayer (wengxt)]

Yes.

[Gunnar Hjalmarsson (gunnarhj)]

@csslayer: Excellent!

OT follow-up question: Do you know if it would be possible to use xkbcommon with IBus too?

[csslayer (wengxt)]

Yeah, it's possible. But someone need to write the code.

[Gunnar Hjalmarsson (gunnarhj)]

Ok, thanks! Then I'm pleased for now. :)

[Gunnar Hjalmarsson (gunnarhj)]

Considering that ibus has already been mentioned in this bug report: ibus upstream has just dropped the static compose tables, and instead loads the X11 tables.

https://github.com/ibus/ibus/commit/7ae585ac21db4dfac8989887e1a5f97fb863fa17

@Aron: Can you tell when this upstream ibus change will be reflected in Ubuntu? I'm asking because it will be a part of the fix of bug #518056.

[Aron Xu (happyaron)]

@Gunnar, can't tell at the moment, I won't want to carry such a large patch even if it's applied in upstream VCS, let's wait for next release.

[Aron Xu (happyaron)]

Fixed in 1:4.2.9-1.