I'm a maintainer of keyboard module and I'd like to see input me= thods integrated in keyboard module. Although I am not sure about replacing= keyboard module altogether - it has a lot of features, I'm open to ext= ending it especially if it's done in modular fashion.

Please note I know pretty much nothing about IM so I would need detailed= information on what is to be done.

Could you please prepare a technical reasoning and details of proposed c= hanges so I and potentially others could evaluate the impact?

On Jun 27, 2012 12:11 PM, "Weng Xuetian&quo= t; <wengxt@gmail.com> wrote:<= br type=3D"attribution">

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<= br> 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 m= ac
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://g= ithub.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?c= ontent=3D146776
2. if possible, replace or change the kcm keyboard to support IMF kcm,
or using external command.

Comments are welcome.

[1] http://co= de.google.com/p/fcitx/
[2] https://pro= jects.kde.org/projects/kde/kdeplasma-addons/repository/revisions/master/sho= w/applets/kimpanel
[3] http://en.wikipedia.org/wiki/Input_method
[4] https://proje= cts.kde.org/projects/kde/kde-workspace/repository/revisions/master/show/kco= ntrol/keyboard

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub= to unsubscribe <<