Re: 3.6 Feature: IBus/XKB integration

[Marguerite Su <i marguerite su>]

On Mon, May 14, 2012 at 8:34 PM, Christophe Fergeau <teuf gnome org> wrote:
> Hey,
>
> I just read the whole thread, and had a few questions, I'm more or
> less arbitrarily answering to this email in the thread.
>
> 2012/5/13 Marguerite Su <i marguerite su>:
>> and another background knowledge:
>>
>> fcitx is capable of inputing in Traditional Chinese( IBus don't make
>> it even work), Simplified Chinese(as I said, top choice if user has
>> choices), Korean( korean Ubuntu users is discussing it in their forums
>> just right now.), Vietnamese.
>>
>> and Japanese is starting in two months after Weng finished his
>> graduation paper. it's for GNOME 3.6 right? he invent fcitx-keyboard
>> in just two days but solid. can't you wait  two month and work on
>> other parts of fcitx?
>
> Did I understand correctly that fcitx does *not* have japanese support
> today but that it should be implemented in the coming months? This
> would mean that fcitx is not a suitable CJK method now as has been
> said throughout the thread, but just a CK input method until Weng does
> his magic ;)
>

Hi, Christophe,

I was a little mix up this thread with the thread on our distribution channel.

here are some background in our thread ( not this one ):

at first, answer your question:

FCITX has J support, mozc.

and fcitx has a experimental anthy.

so you may ask: why doesn't finish anthy then start mozc?

mozc is actually like Linux version of Google Japanese IM.

and anthy/canna/skk/wnn are all IM engines in SICM era.

so Japanese is like us Chinese, prefer to use mozc as a better
choice.(so Chinese nowadays even know mozc.)

since FCITX takes users choice as the first priority. they do mozc
first. that's something development schedule.

then I proposed to select MOZC as Japanese default IM in openSUSE DVD
since it's the users' choice.

but then maintainers of MOZC told me although mozc is FOSS, it's close
development. so it's hard for us(I'm one of mozc maintainer too) to
maintain it as a distribution's default IM.

that's why we temporarily kept ibus-anthy as default IM in DVD, until
Weng finished fcitx-anthy (as you know, J community is tired of
IBus-anthy too, too old, too buggy. and they're actively involved in
testing now).

so it's not FCITX doesn't has J support. but is J community decides
not to choose mozc as default IM although they use it on a daily basis
and prefer it as better choice. they calls for
fcitx-anthy/canna/skk/wnn as default IM, although they'll use mozc as
their "actually default IM".

:)

> This leads to my next question, this thread so far has been focused on
> CJK (and Vietnamese in this email). Are they the only languages that
> needs input methods? Or are they needed too for arabic, hebrew,
> thailandese, ... ? If yes, is fcitx the IM framework to use for these
> too?
>

to be honest, CJK developers build IM framework, others build local
engines.(but there are still many much more engines in CJK than
others) that's why we focus on CJK here. because as IM, if you can't
support CJK to input with hobby and pleasure, even if you success in
all other areas, it's hard for you to call yourself as a "framework".

and if framework is good, engines catch up more quickly than you think.


CNS11643, Compose, Emoji, Ipx-x-sampa, Latex, Rustrad,
Thai, Translit-ua, Translit, Viqr, Yawerty.

these're all other non-CJK engines IBUS and FCITX both support. is
there any engine IBUS supports but FCITX not? no. at least for
openSUSE. because I almost package and maintain every IM in openSUSE,
SCIM/IBUS/FCITX. and I think openSUSE community is large enough to be
considered as a sample.

actually SCIM's multi-national support is the best. but you've already
had a conclusion why no SCIM. because it does not even ever support
GTK3.


> Having an IM abstraction framework has been one recommended by some
> people in this thread. One concern I have with that is that the
> fragmentation we have now will stay, and we'll have the foo IM
> framework which will be favoured by people who want to input language
> A, the bar IM framework will be the best for language B. In such a
> situation, people who want to input both A and B (think A speaker
> learning the B language) will not get a satisfying user experience.
>

but the fragmentation now partially comes to an end.

the demand to input both A lang and B lang is now provided by Weng.

you can even use fcitx-hangul(K) in one chat conversation,
fcitx-pinyin(C) in another.

and to talk about IM users' mixed input experience, you must know the
languages IM users often use mixed. that's, English and mother
language. or vice versa. that can even done by an IM without English
support, right?

another IM mixed situation is between C and J/K. since every IM has
CJK support. that's not a problem.

and mixed input between French and German? that's what keyboard do. we
just provide fcitx-keyboard(IBUS doesn't have it yet) and
fcitx/ibus-m17n.

and between south-eastern Asia and CJK? well, thai, vietnamese can be
both mixed. and many people in that area even write in C and speak C.

between Arabic/Hebrew and CJK? that's a too small user database.
that's why we CJK interact with them using English, like to you. that
hypothesis is almost based on thin air. there are too few CJK know
that language, and that will make a lot of money, they can't be even
satisfied by LINUX but MAC.

so mixed-up input experience is the same under FCITX and IBUS.

if that's what you and GNOME developers are worrying about.

:)

> Finally, please correct me if I misunderstood, but after reading the
> thread, I'm under the impression that ibus and fcitx work equally well
> to input CJK "characters" (except for a few ibus bugs that I guess
> could be fixed?). What makes fcitx better is that it provides advanced
> functionalities such as word autocompletion (+ highly customizable
> autocompletion window and online autocompletion lists), "macros"
> (short key sequences that will get replaced by a full word), ... My
> feeling about these advanced functionalities is that they are not
> really CJK-specific, and that this could be useful too when typing
> English or French texts, in which case this may be worth integrating
> at a higher level instead of having this in the input method? I guess
> the answer is that they are different things, but asking does not hurt
> ;)
>

yes, that's useful for western users too. but not the thing DE should
do. all they have to do it together at least. reasons:

1. then if KDE doesn't do it, there'll be no IBUS but GBUS...because
if a feature has been done by GNOME, then no need to implement it
again on IBUS. the what about IBUS user experience on KDE? you know,
IBUS is at first a cross-over IM then a DE integration to be. that
means IBUS has to implement it again on its own. then GNOME don't need
to do it from the beginning, right?

2. even if KDE/GNOME both done this, what about a mobile phone? an
openbox? a xfce?


> Christophe


Hope it helps

Marguerite