Re: 3.6 Feature: IBus/XKB integration

[Aron Xu <aronxu gnome org>]

Hi,

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.
>

These are _almost_ correct for GNOME, and it has self-explained why
it's a bad idea. Most GNOME developers aren't CJK users, so making any
assumption can be really risky.

It's not that simple to say whether a "working" input method framework
is good enough for average CJK users. Tremendous strides have happened
in the field of input method on other platforms, say Windows, iOS and
Android. Those progress are not acknowledged by most Linux desktop
vendors (either upstream ones like GNOME, or downstream distributions)
in recent years.

This leads to an embarrassing situation of Linux desktop input methods
- developers tend to think the ability of inputing characters is the
only important thing, and user experience researchers look only at how
existing Linux users do with existing input method frameworks. This is
troublesome, because we've already lagged behind but we're still
trying to build our own wheels, without the desire of knowing how
others have already done.

> 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.
>

True, users usually don't care about what's input method framework,
less about how it talks to other applications they are using.

But they do care about many details of the functions, like defining
own shortcuts, modifying the details of candidate ordering, add or
delete some words from dictionary, how the user interface is displayed
and how the candidates are shown (in very very detailed manner),
whether they can sync there user-defined settings to the cloud so it's
ready wherever they need them, etc.

What is a "good" input experience is not kind of thing that can be
easily imagined base on existing assumptions among Linux desktop
developers because users are so nit-picking on other platforms
already. They do care about whether the stuff works, but it's basic
thing anyway; they also care about whether his/her stuff is cool,
which includes but not limited to easy retrievable/changeable skins,
hot words live updates, cloud candidates words, etc. Some people even
change the skins in a timely fashion, say one day/week per skin - and
it's important that doing so is too easy, just browse the online
library and click, all done. If you do visit the offices of non-IT
companies in China, you'll find what I've described is too few
comparing what they have and use everyday.


> 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.
>

Yes, but why not making the integration a plug-able system? Providing
an interface that input method frameworks can talk with, for example
gnome-control-center.

I read there are people saying they want to end the diversity/mess of
input method framework in GNOME by doing so, but we all know such
decision can't be made by developers in reality, users will choose
whatever they feel more comfortable.

It's good to recommend and promote something for collaboration, but
it's definitely bad to bond to something with the risk of being
irreplaceable in the future. Input method is something unique than
other applications like music player because of its nature of talking
with all applications that user needs it to.

> So, please make the argument that fcitx is better and more aligned with
> the philosophy of GNOME and should be used instead of IBus!
>

Even with the above concerns, I vote for Fcitx if we have to make a
choice. Let me start with your sample questions:

> 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?
>

Yes, and screenshots are already shown by Weng. The UI still needs
some input from professional designers to make it better fit into the
desktop.

>  * Does fcitx have better feedback to the user while they are entering
>   input?
>

Short answer: Yes. Input speed, input time and character count are
shown by default for Chinese users.

There is almost no overhead to support features like this because
there is an integrated plugin system in Fcitx. Input method engine
developers can focus on implementing core algorithms, other common
functions like the way of dealing with punctuation, skin support,
cloud integration, quick phrase, full width character switch, are
automatically added at runtime whenever possible by the framework.

The overall architecture of Fcitx is highly modularized with well
abstracted layers of functionality. Above is an example of the
advantages brought by such architecture.

>  * Does fcitx have better dictionaries and algorithms in its input
>   methods?
>

Short answer: No. All existing input method frameworks share almost
the same dictionaries and algorithms.

There are minor differences in a framework's default PinYin engine, so
scim-pinyin, ibus-pinyin and fcitx-pinyin are not the same thing. But
comparing with more advanced, dedicated PinYin engines like Sunpinyin
and Libpinyin, they are just providing similar features with similar
experience.

>  * Is fcitx less buggy?
>

Bugs always exist, but most noticeable bugs affecting input experience
are in X and UI toolkits, not in IBus or Fcitx. Here are several
obvious/long-standing examples:

1.GTK+ 3 reuses the variable GTK_IM_MODULE, which has already caused a
lot of pain for distribution makers. When GTK+ 3 IM Module aren't
available on system, but GTK_IM_MODULE variable is set, all GTK+ 3
based applications lost input method support.

This can be workaround by always installing GTK+ 2 and GTK+ 3 IM
Modules together. But users tend to be unhappy with increasing
dependencies. Qt4 has a separated variable QT4_IM_MODULE to
distinguish from Qt3's QT_IM_MODULE when needed.

2. The first problem can be tolerated in some degree if GTK+ 3 can
properly fallback to XIM when GTK_IM_MODULE is set but not usable. But
it didn't work for a long time. And XIM support in GTK+ 2/3 isn't that
perfect (comparing with Qt4) at any time.

3. We have asked that key events must be passed to input method
framework before passing it to anything else, but the request is
always ignored. This makes many applications "eat" some random key
events while the event is important for specific user experience.

--
Regards,
Aron Xu