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