Complex text input in Plasma

[Shinjo Park]

Hello list,

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. [1]

[1] https://code.google.com/archive/p/ibus/issues/1726 and https://
bugreports.qt.io/browse/QTBUG-40541

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.

Martin Gräßlin:
> 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.

Martin Gräßlin:
> That would be an option if we want to support multiple IM
> implementations.
> 
> 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
> core.

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.

Shinjo