Complex text input in Plasma
kde at peremen.name
Fri Apr 14 11:11:36 UTC 2017
I was not following this list but the discussion was interesting, so I am
adding my opinion/personal mumblings/etc. to this topic.
For entering Korean texts, the expectations and requirements of IMs are
different from Chinese/Japanese. As most multilingual IM cores are designed by
C/J community, the difference is sometimes overlooked. Unlike C/J where all
composing is explicit, Korean users are expecting implicit commits when the
textbox loses focus. Changing this behavior is not acceptable as this is what
we expected from the beginning of PC. Some IMs did not handled this behavior
correctly in past, and this was not clearly solved for several years. 
 https://code.google.com/archive/p/ibus/issues/1726 and https://
Some Korean users (including me) are thinking current IMs in Linux desktops
(fcitx, ibus, etc.) are somewhat overbloated, since entering Korean texts does
not really require the typical features used by C/J ((personalized)
dictionaries are not typically used, numbers and punctuations are always half-
width). Even though I am using fcitx right now, this change was somewhat
"forced" as Qt 5 dropped XIM support, and I had to abandon the good-old Nabi
who supported just XIM and handled only Korean.
> I dislike all three options. The base keyboard layout handling must be
> in KWin. KWin has to control the IM stack, not the other way around.
> I'm not giving away control over such fundamental aspects of the stack
> any more. I want that these things function correctly and I'm not
> trusting 3rd party software to do the right things.
+1 from my side to be consistent. I enabled Korean, Russian and German
keyboard layout via systemsettings, and expecting IM is only enabled when the
layout is set to Korean. I had to configure those in fcitx also to make it
consistent, and sometimes keyboard layout got scrambled upon changing window
and have to manually reset the layout as I want. And I also had to configure
fcitx to respect my xkb options (and do not reset it upon changing IM) too.
> That would be an option if we want to support multiple IM
> But if we want to keep it small and simple I would go to directly link
> the fcitx library and do the deep calls into fcitx directly from KWin
I am opposing integrating specific IM into KWin core as we don't know how IMs
and its APIs will change in future. There were quite a lot of IMs throughout
the history (scim, ibus, fcitx, uim, ...) which changed from time to time. But
if a stability in functionality and API is guaranteed by integrating some IM
into KWin core I would not object it. I am personally reluctant to change IMs,
as it might introduce a new bug in handling texts, and Korean plugin for all
those IMs are almost the same in functionality.
More information about the Plasma-devel