Re: 3.6 Feature: IBus/XKB integration

[Tommy He <tommy he linux com>]

I'm kind of worry about the echoing sound that CJK user bases
represents all the needs for a input method *framework*. It's NOT.

Take a look at these:
http://fedoraproject.org/wiki/Features/IndicTypingBooster
http://fedoraproject.org/wiki/Features/english-typing-booster

Also here are the packaging situation for iBus on Fedora:
https://apps.fedoraproject.org/packages/s/ibus
It seems to be better than that on openSUSE but I don't see anything
significant other than the additional typing boosters.

Another worrying trend I feel while reading this thread is that
comparing input method based on the availability and quality of
engines. As Fujiwara suggests, "focusing each IM engine would not be
good to pick up the default IM framework".

>From my experience on project management and evaluation, I would like
to initialize a few questions to head to this direction:
1. What are the essential features for a input method *framework*?
2. How good/buggy the iBus and FCITX are on above essential features
respectively?
3. The availability of input method engines supported by iBus and FCITX.
4. The quality of each input method picked from the above.

We may continue to ask ourselves more questions like above until the
evaluation form is created. It would a bit harsh to say which input
method *framework* is better if we don't have a clear standard.

Tommy

On Tue, May 15, 2012 at 1:46 PM, Marguerite Su <i marguerite su> wrote:
> 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
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
Take a Deep Breath out of Windows