Refined fcitx config gtk3

Some may noticed the screenshot I posted on the twitter, yes, fcitx-config-gtk3 now has a new refined user interface.

I can hardly say it’s perfect, but at least looks better integrated with gnome3 default theme. (Well, the KDE style doesn’t fit gnome, this is one of the lesson I learnt this time).

I found currently it’s impossible to integrate into gnome-control-center for third party (the required header are not installed), so it might keep standalone for a while. By the way, I will not continue to work on gtk2 version for new style, but still it have some new feature. For example gtk2 version can also launch a addon configuration from command line, but the new feature will only goes into gtk3 version in the future. Gtk2 version will keep it’s old library dependency, but that will not prevent me from using newer library for new feature.

By the way, fcitx will have GIR support in 4.2.4, thus you can control fcitx from script easily, including fcitx-client for implementing input method client, and fcitxkbd for controling keyboard layout related stuff and fcitxinputmethod for controling fcitx itself.

=-=-=-=-=
Powered by Blogilo

Posted in 日志 | 8 Comments

Keyboard layout binding

As I say in this https://www.csslayer.info/wordpress/fcitx-dev/keyboard-layout-will-be-first-class-in-fcitx/ , fcitx will have keyboard input method by default. And actually for all input method they have an layout by default, for example, Pinyin is “English (US)” and Mozc is “Japanese”.

But there are some alternative layout, for example Dvorak, that is not used for specific language, for example, Arabic, how can easily make people can use such layout?

Answer is this:

The video shows a new feature to override the default layout setting for input method engine. (Notice, keyboard layout input method itself cannnot be overrided, things like force “Keyboard – English (US)” to use “Japanese Layout”  doesn’t make much sense, so I make it impossible).

Hope you like it.

=-=-=-=-=
Powered by Blogilo

Posted in fcitx development | Tagged | 6 Comments

这是无聊的牢骚

因为是牢骚,所以是日志分类。

世人皆知,折腾网页兼容性,人见人骂爹,不过估计还没人想到还有…

他们需要开十几个虚拟机,装遍某平台下所有桌面,甚至测试的浏览器比折腾网页兼容性的人还多,用过的窗口管理器估计也超过大部分WM爱好者,用过的编辑器的数量也绝对不少。

……

不过这些都是必要的……

Posted in 日志 | 6 Comments

Keyboard layout will be first class in Fcitx

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

Posted in fcitx development | Leave a comment

Some Conclusion on GNOME

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.

Posted in fcitx development | 3 Comments