Re: Bug#680668: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)
On Fri, Feb 1, 2019 at 3:38 AM John Paul Adrian Glaubitz
> > On Jan 12, 2019, at 10:02 AM, Yao Wei (魏銘廷) <email@example.com> 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?
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.