Re: 3.6 Feature: IBus/XKB integration

[Weng Xuetian <wengxt gmail com>]

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 ;)
Well, actually fcitx have fcitx-mozc, already being packaged by
opensuse, reviewing by debian. (And as I'm also a packager for chakra,
but maybe not worth mention).
And I really going to implement something more in coming months.
>
> 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?
Yes, m17n support and keyboard layout support are also done and
packaged by debian, ubuntu, and opensuse.
>
> 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.
>
> 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
> ;)
fcitx provides a quite more power plugin system, for every single
plugin could enhance multiple input method.
Though currently most of them are aiming to support CJK better, but
for the system they can also work for other language, but we don't
have an good idea about what to do.

Yes, you're right, fcitx already provides word autocompletion with
integrated with keyboard layout.

A single screen shot will explain it all.
http://fcitx-im.org/wiki/File:Fcitx-Keyboard.png

The autocompletion dictionary will changed when you change keyboard
layout for another language.

And a macro-like plugin http://fcitx-im.org/wiki/QuickPhrase, though
it's disabled when using keyboard-layout based input method (Since I
cannot decide whether it will brings too much interrupt to type for
such user.