Re: 3.6 Feature: IBus/XKB integration

[Marguerite Su <i marguerite su>]

I'm going to "fix" this email with explanations on the tech bits he
referred, in plain English.

And I can't be more plain English than Justin Wong's. so I won't
explain his email(s). as I said, someone has already started a
conversation with him.

And Liang's email just provides some facts, so no need to explain, and
you guys can see it in reality in Hong Kong, June. so no need to
explain too.

On Sun, May 13, 2012 at 3:34 AM, Aron Xu <aronxu gnome org> wrote:
> 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.
>

he said you can't "make" facts but to base on our facts. because we're
the users.

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

he said "to input" is not enough for CJK users. but to customize.

he said mobile and other OS is making big progresses in IM field.

and unluckily GNOME/Distros fail to absorb such bits, either
technically or in user experience.

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

he said the gap between developers and users.  developers like you
think if you can input using an input method, what else do you want?
but indeed users don't even care so much about "to input", because
that's what an IM should be, they care much more on other feature to
make an IM rich and unique.

and developers only listen to the users and study the behaviors of IM they know.

he said we Linux have already lacked behind by other (mobile) OSes.

so if we do not open our heart, learn what they achieve in other
fields but to close the door and building our own stream engine.

we'll never catch up.

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

he said users don't care about implementation but features themselves.

those features are (partially):

1. customize shortcuts to switch IMs or trigger some behaviors, like
to input special match functions

2. if you input "abcd", the IM will return you options "1. me", "2.
you","3. he",

users may want to manually arrange the order, because he uses "2.you"
most. so he want to change 2 to 1

3. users input "I love you so much with all my heart GNOME!" many times a day.

so he may want to add that sentence into dictionary ( to make his own
dictionaries easily)

then he input "IlysmwamhG" for that sentence. with prediction, he just
need to input "Ily".

life is pretty much eaiser, aha?

4. users want to switch the skin of the input panel, to make it more
better looking under certain OS, like green color for openSUSE, blue
for Chakra.

5. users may need to customize how are options are shown.

instead of "2. me", he may need " 2. 'me', used to represent 'I' after verbs".

6. like dropbox, user may want to sync his config and customization
onto some place over the internet. when he goes to his office he can
just launch computer, sync with server, then "Ily" again without any
repeated customization.

can IBus do it now? no.

can you implement it for IBus? no.

that're some common features nowadays CJK IMs have. but IBus not.

so be compulsory on IBus may not be a good idea.

because by doing so, we're actually taking something users already
have away, that's even worse than we never give them.

and that's exactly the reason I said "users will leave, a lot many".

it's like when you don't have a PC, you go to Net Cafe.

but if you have had a PC, I bring it away into my house, and ask you
to go Net Cafe again.

you'll fight.


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

he said users have been familiar with the advantages IM on other OSes gave.

so it's not what you only know a half-functional IM can imagine, you
have to listen to guys focusing on IMs.

users not only care if a IM can input, but also:

1. change the way it appears, skins, themes.

Chinese change IM skins based on emotions. like I'm angry, I change it
green. I'm blue, I pick up a blue one. I'm happy, a red one.

it's like emoticons in western countries.

Will you implement an OS has no emoticons? nope.

then it might be not a good idea to implement IBus that tight.

and there're many Chinese designers making just skins for customization.

what you do will ruin their "market".

2. fetch hot words from internet servers. eg:

you may never heard of Obama before he's president. his name may not
in your dictionaries.

that's possible. because Chinese has too many "words". it's something
like the sentence "what the hell" in English, but we called it "word",
because we do not split words like you do using white space. we just
put what you call word together to make new "word", the new word might
be "whatthehell"?

then it's not possible for any dictionaries to contain all of them.
CJK IMs only default ships a common word database.

then Obama might be not in our database. we have to sync it from
internet servers.

IBus can't. so you can't even talk about affairs of your president. or
every time you talk about him, you have to manually put "OB" "A" "MA"
together to make your word.

then will you still happy to remove such features?

his point is, you'll never know what a CJK IM can be like.

it's a big internet culture. so it's better to accept it and adapt to it.

or GNOME will be forgotten very quickly by those CJK communites.

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

he said you should provide an  universal protocol and standard for IM.

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

he said minimal option with IBus is not possible. never.

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

he said you can't bind IM with system because it's the first and only
program user faces
when using all other programs.

if it sucks, then system sucks. so can you be 100% sure it won't suck?

no. so not possible to absorb an specific IM into GNOME.

then if it sucks, users can change. system is still good.


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

he voted for fcitx. and he said IF YOU DO WANT A SINGLE SOLUTION

it will be fcitx. but please don't use "single" solution.

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

he said fcitx is easy to users. but if someone like gnome artists come
to polish it more, it's welcomed.

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

he said fcitx will give you every detail you may want when you
actually input using it.

it can returns you not only the options, but also the speed you type,
how long you have been typing, and word count.

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

he said fcitx has a plugin system. you can easily add new languages.

cloud integration: google/sogou/baidu/tecent has their servers
containing many words, so if you can't find your word in your IM
dictionaries. fetch them online. and the servers even can correct your
mistake.

quick phrase: you can use "h" to input "hahahahahahahahaha", that's
LOL in China.

full width switch: a CJK letter holds 4 bits, but you can make it 8
bits. thus in terminal, it has a better looking, because enough space
between each characters. like your monospace.

> The overall architecture of Fcitx is highly modul
arized 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.
>

he said you misunderstood. basically IM has two parts:

algorithms: the way to judge which letters can be grouped together,
and if they're a word. and to match which word it is exactly. like to
split "what the hell" from "whatthehell"? and some possibilities to
deal with "hatthell".

framework: IBus/Scim/Fcitx.

in low-level they're the same. so to talk about IM, you have to focus
on other functions except the "how to type" thing. because it's the
work of upstream of the IMs we're talking here.

>>  * 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:
>

he said most of the time bugs of IM framework come from upstream
projects like you because you did not take IM into consideration.

so most of the time it's not IM developers to fix their bugs. but you
to fix yours.

below are examples easy to follow since you're a coder.

> 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
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

explanation finished.

so as you can see, what you think of an IM is not what actually an IM is.

it's not an easy topic to get involved in.

still a lot to learn from them for a non-IM user and developer.

Marguerite