Re: 3.6 Feature: IBus/XKB integration

[Weng Xuetian <wengxt gmail com>]

On Sat, May 12, 2012 at 10:51 PM, Owen Taylor <otaylor redhat com> wrote:
> Hi Maguerite,
>
> Thanks for the detailed response!
>
> It's hard for me to talk about the pros and cons of fcitx and IBus -
> sadly I don't speak or write Chinese, and I haven't investigated the
> technical operations of these systems either.
>
> But what I do want to talk about is the user experience we try to create
> in GNOME. In general, our goal isn't maximum choice. It's the best
> possible experience.
>
> A user starts using GNOME. They have trouble inputting Chinese text.
> A friend sees their computer, tells them to uninstall IBus and install
> fcitx. Things work much better. Is this a success of Free Software?
> No - it's a failure. We gave the user an operating system that didn't
> work until someone fixed it.
>
> In my experience, there is almost no chance most users will understand
> the concept of an input method framework. Users are busy talking to
> their friends, doing school work, or inventing the cure for cancer. They
> don't want to take a course in how their computer works internally. We
> can provide options behavior - are they using Pinyin or the Four-Corners
> method? But we shouldn't give them options for how applications talk to
> the input method.
>
> We also really value using the same basic components on all GNOME
> systems. You hit a crash on your system in GNOME Shell when using
> fcitx, and you report it in GNOME bugzilla. If I'm using fcitx, then
> I can reproduce the bug and fix it. If I'm using IBus or no input method
> framework, then the bug may never be fixed.
>
> Users should also be easily able to mix and match and switch between
> languages. This means that we need an input method framework that works
> well for all the input methods - we can't have one input method
> framework for Chinese, and another for the languages of India.
>
> So, please make the argument that fcitx is better and more aligned with
> the philosophy of GNOME and should be used instead of IBus!
>
> The best way to make that argument is to explain it to us -
>
>  * Does fcitx allow for an easier-to-understand configuration user
>   interface? Do you have screenshots?
Gtk
http://fcitx-im.org/wiki/File:Fcitx-configtool.png

KDE
http://fcitx-im.org/wiki/File:Kcm-fcitx.png

Currently two implemention is like a centralized control center, and
the idea of fcitx UI is free to choose how to express it, so if some
day if we need another totally different toolkit, it could be made,
even clutter or ncurse.
>
>  * Does fcitx have better feedback to the user while they are entering
>   input?
I don't really understand this. If you talking about preedit, or
surrounding text, both fcitx and ibus supports them.
If you talks about UI, all ui element are necessary and nothing more.
>
>  * Does fcitx have better dictionaries and algorithms in its input
>   methods?
>
For algorithm, fcitx and ibus share a large number of library. But
some differences in architecture make fcitx have more features, which
are important for users.

Let me list them in details.

Chinese:
Pinyin they shared quite a lot of library, but fcitx have this:
http://fcitx-im.org/wiki/Cloudpinyin in among all pinyin engine, it's
an important the reason that Chinese user prefer fcitx.
Even for new Libpinyin which only appears in fedora, ibus's libpinyin
implementation is really bad, and fcitx would support traditional
chinese better in this part.
Table: I have heard people complain about ibus-table is hard to use.
Chewing, nothing different.

Korean:
Hangul: nothing different, but fcitx can have this
http://fcitx-im.org/wiki/QuickPhrase (actually this works with most
input method)

M17N
nothing different.

Japanese
Fcitx have mozc for now, for mozc nothing different.

Keyboard layout integration:
Fcitx will win in this part, it have variant support, word completion
and spell check based on enchant (Done) or presage (WIP).

>  * Is fcitx less buggy?
This is hard to tell, since the most bad part for input method of
linux is bug in UI toolkit. Most of input method in *nix world is
because of that.

I have maintained a list here actually.
http://fcitx-im.org/wiki/Hall_of_Shame_for_Linux_IME_Support

If you want to compare bug list:
http://code.google.com/p/fcitx/issues/list,
http://code.google.com/p/ibus/issues/list, but it doesn't reflects the
fact. Seems ibus guy don't like to clean up the list though.

If you need some extra feature, fcitx provides details manual for how
to use it, while ibus feature is poorly documented.
>
> - Owen
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list