From kde-devel Wed Jun 27 16:10:34 2012 From: Weng Xuetian Date: Wed, 27 Jun 2012 16:10:34 +0000 To: kde-devel Subject: Input method integration Message-Id: X-MARC-Message: https://marc.info/?l=kde-devel&m=134081368017885 Hi, I raise this question maybe because gnome guy recently is doing some thing similar. Well, first I'd talk a little about myself.. I'm main developer of fcitx [1], and currently maintain kimpanel [2] in kdeplasma-addons, so mainly what I have done in linux world is all about input method. If you guys are not familiar with input method [3], input method is an application provide text input service, for CJK people, input method is a must to let people type in their native language (also needed by other people, but CJK people use them most). You could think that as "text conversion service", and some input method engines are just like keyboard layout, but most of them are more complex. Input method framework (IMF) is a service that provides a bunch of different engines for different languages, and not be easy to changed at runtime. Current state of input method outside linux world: Windows and mac manage keyboard layout together as input method, so a keyboard layout is just a "special" input method in windows and mac world. They have a unified configuration UI to add, remove, sort input method. For KDE, KDE provides a UI for configure keyboard layout [4], which maybe replace or extended to show and configure input method. For desktop there are several IMF , scim is not active developed for a long time, uim, gcin/hime, ibus, and fcitx. IBus and fcitx both provide some easy way to manage input method via dbus. All existing ibus setup is mostly based on pygtk and gtk. For fcitx itself, I've already work on http://github.com/fcitx/kcm-fcitx/, since it provides something like kxmlgui so it's more easy to make it toolkit free. For plasma guy, if you know about Maliit, maliit is also a IMF specialized for on-screen typing. But let's talk about desktop for now. For both ibus and fcitx, there are some function duplication with kcm_keyboard and kded_keyboard itself. From my point of view, it would be better to let input method manage the keyboard layout, which may need to hide the existing kcm_keyboard part and replace it with IMF configuration. For fcitx, I've already implemented https://github.com/fcitx/kcm-fcitx/ and it's already packaged by distro for sometime. But this time I'd also like to see deeper integration for input method inside KDE. So my proposal it something like this: 1. add a default application option for different IMF, and set corresponding environment variable required by IMF. I have a toy kcm for this idea at: http://kde-apps.org/content/show.php/kcm+imchooser?content=146776 2. if possible, replace or change the kcm keyboard to support IMF kcm, or using external command. Comments are welcome. [1] http://code.google.com/p/fcitx/ [2] https://projects.kde.org/projects/kde/kdeplasma-addons/repository/revisions/master/show/applets/kimpanel [3] http://en.wikipedia.org/wiki/Input_method [4] https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/show/kcontrol/keyboard >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<