Re: IM Integration: Let's demonstrate our languages in the Wiki



Hi,

First thanks your work on the Wiki page, and I'm sure it can be merged
into either part. I find the example case you've made to tell the
procedure of imputing on Windows is especially good, thanks!

On Mon, Jun 4, 2012 at 12:44 PM, Kunshan Wang >
> About IBus and Fcitx
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> The IMF I first used is SCIM, then IBus. IBus-pinyin sucked before
> because it was slow and un-responsive. Now ibus-pinyin sucks less. The
> IBus IM panel disappeared since GNOME3, which I think is not good.
>

This is easy to be solved using DBus + GS plugin.

> I have not used Fcitx before. But I downloaded and tried Fcitx and
> felt it quite usable (in the sense of responsiveness). Fcitx is more
> traditional (in the sense that it resembles the good old IM softwares
> in the M$ Windows OS) and surprises me less. But I don't think an IMF
> using a config file written in Chinese (Fcitx) can be world-wide
> acceptable.
>

Starting from 4.0.0, Fcitx has been re-constructed from the ground and
is designed to be an even more modern IMF. It was its long history
leading to many misunderstanding that it was targeted at Chinese only.

If you don't want to dig into too much technical details of why it's
"more modern", I believe the following link can help you understand
why it's not not Chinese only at least:
http://packages.debian.org/search?suite=sid&keywords=fcitx

In the just released 4.2.4 (which haven't been uploaded to Debian
yet), fcitx-keyboard (the xkb support module) has been merged into the
main package, which is now aiming at implementing an integrated
input-sources user experience. More tables are also coming, and all
existing tables included by SCIM and IBus are available (the last bits
are released with 4.2.4 yesterday night).

We are against the integration of IMF in GNOME and the reasons and
concerns are well explained before, it's not only a race condition but
also technically too broken. It's easy to understand: if GNOME can
integrate IMF and XKB using a virtual layer of input-sources, why
those IMF developers spend so many time to implement XKB support
(ibus-xkb, fcitx-keyboard)? No, it's surely not because all of them
are stupid.

--
Regards,
Aron Xu


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]