On Fri, Feb 1, 2019 at 3:38 AM John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> wrote: > > Hello! > > > On Jan 12, 2019, at 10:02 AM, Yao Wei (魏銘廷) <m...@debian.org> wrote: > > > > or we can follow task-chinese-s-desktop and use fcitx instead of ibus in > > task-chinese-t-desktop: > > > > fcitx, > > fcitx-chewing, > > fcitx-table, > > im-config, > > fonts-arphic-ukai, > > fonts-arphic-uming, > > fonts-noto, # this seems to be unnecessary, but not really sure. > > fonts-noto-cjk, > > libreoffice-l10n-zh-tw, > > libreoffice-help-zh-tw, > > firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw, > > poppler-data > > I haven’t yet understood why people are moving to fcitx. I have tried it > myself after it was automatically installed on my openSUSE machine to replace > iBus and found it completely unusable. I didn’t even manage to get any input > languages added. > > I am using iBus for writing Japanese and I consider it the superior and > simpler-to-use solution. > > Is there anything that fcitx is supposed to do better than iBus? > > Adrian
One of the reasons people moving to fcitx is that the framework has some architectural advantages that gives a lot room of extending the input method which ibus does not have so far. An example for Chinese (China) users is that there are several other alternative implementations of UI and, even further, commercial products with both UI and engines. GNOME's built-in support for ibus is a very old topic that a lot discussions happened on GNOME's mailing list years ago - in short there are two reasons: 1) ibus has slightly better support for those non-CJK languagues whereas GNOME developers are mostly non-CJK native speakers, 2) RedHat has continued investment on it. Cheers, Aron