I have argued with some people, that keyboard layout should be managed by input method framework or not, my opinion is yes. Keyboard layout and input method engine is just like two dimension, but they should not combine freely to produce some meaningless result, for example, pinyin and German.

Actually English (US) layout is even a “very” basic component, even xkb not available, there will always be one of this layout, and it will make the logic cleaner.

fcitx-keyboard will be merged with Fcitx, and there will be some fundamental changes in fcitx.

1. there will not be three state, but only two state. Active and inactive. Active will be your favorite IM you choose, and inactive will be the IM at the first of the list.

2. Trigger key, which is ctrl+space by default, will be the exact “same” function with the switch key. Which is left ctrl for now.

So switch to “english” will be simply switch to the first layout. There isn’t anything hidden or magic in the future. For example, the input method will actually always be active.

This target will be accomplished after the merge:

https://www.csslayer.info/wordpress/fcitx-dev/make-fcitx-like-a-system-component/

There will be another function (not yet implemented), that can configure input method to “bind” with a (maybe more than one, I haven’t decide yet) non-default layout. Which means you still have a way to use Dvorak with pinyin, and fcitx will remember your decisiion, but the thing like using German layout with pinyin will not likely to happen for normal user :).

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.