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 :).
