1.

Being able to use other IMF or not, answer is yes.

https://mail.gnome.org/archives/desktop-devel-list/2012-May/msg00226.html

The other IMFs will likely continue to exist. They will require users to
make changes to their systems to use them (just like right now if you're
not using the default IMF for your distribution), and you won't have
integrated preferences (just like right now).

2.

Compile time dependency of ibus (Comparing with “runtime dependency”), might or might not get dropped.

https://mail.gnome.org/archives/desktop-devel-list/2012-May/msg00193.html

So that’s all. Though “2” doesn’t completely satisfy me, but is acceptable for me.

I will still work input method on Linux and target for better user experience with input method, this is never changed.

As I have stated many times in my blog, the most serious problem of input method in linux world is not input method, but actually the application. That’s why I maintain a page of applications with buggy input method support.

http://fcitx-im.org/wiki/Hall_of_Shame_for_Linux_IME_Support

Actually I haven’t worked hard on reporting bugs to application themselves. But now I decide to help them fix their problems in the future, with more concrete description what theirs bug is.

Recently I tried to fix an input method bug in kate (though a rarely used feature, so don’t worry).

Though I cannot fix code I’m not familiar with (no I really can’t, there are huge monsters like firefox or libreoffice, or emacs, even gtk will look like a small kitty comparing with them), but more accurate description of bug report may help upstream application more.

There is another problem, that I cannot use all applications (for example I only use firefox, so I’m not be able to notice chromium bugs), but normal user can hardly describe a problem accurately, so if anyone found any reproducible problem (yes, this is very important, otherwise there might be no bug or just because of some careless operation) may related to input method, feel free to send it to fcitx@googlegroups.com and I will take a look at it.

Here comes a new feature for fcitx in next release.

(Though video is in Chinese, it’s easy to understand. I’m trying to make three different windows to using different input methods.)

The basic idea is, user can choose a different input method based on window. Generally, fcitx can have two global input method, for Active and Inactive state.

Now we can have a different “local” input method for each input context, and it’s easy to choose.

You can talk with different friends in different languages at the same time, for example, you want to talk with your American, German, Chinese friends at the same time, just change the message window, and no need to worry about to switch between different input method.

Before those NIH guys harm the world.

Thanks @doublechou’s first shot.

http://lists.opensuse.org/opensuse-factory/2012-05/msg00169.html