<p>If we're just adding, not replacing, I'm totally for adding IM module.<br>
If that works well enough we can consider tighter integration to benefit from IM advantages</p>
<p>Andriy</p>
<div class="gmail_quote">On Jan 26, 2013 10:14 AM, "Weng Xuetian" <<a href="mailto:wengxt@gmail.com">wengxt@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Saturday 26 January 2013 13:03:29，Todd :<br>
> On Sat, Jan 26, 2013 at 3:41 AM, Andriy Rysin <<a href="mailto:arysin@gmail.com">arysin@gmail.com</a>> wrote:<br>
> > On 01/15/2013 03:11 PM, Weng Xuetian wrote:<br>
> >> Hi,<br>
> >> Under linux, input method is always being a mess:<br>
> >> 1. Start it correctly<br>
> >> ubuntu, debian: im-switch, im-config<br>
> >> fedora: imsettings<br>
> >> opensuse: their own script and I don't really know package name about it.<br>
> >><br>
> >> im-switch and im-config have bug so long time, and all of them are distro<br>
> >> specific.<br>
> >><br>
> >> 2. Relation betwen keyboard layout and input method<br>
> >> Agree it or not, keyboard layout is only a kinds of special input method,<br>
> >> and<br>
> >> it should live with input method,<br>
> >><br>
> >> Now, more and more input method are taking care of keyboard layout (which<br>
> >> means it would just conflict with kde's own keyboard layout settings),<br>
> >> but<br>
> >> it's the correct way to go:<br>
> >> Here comes my beloved usecase :D<br>
> >> User is using a Chinese input method, which expect it to be something<br>
> >> similar<br>
> >> with qwerty, but if you're using a de layout, it will type some non-sense<br>
> >> character.<br>
> >><br>
> >> And idea is, input method have layout on its own, and should be take care<br>
> >> by<br>
> >> input method itself (if they can).<br>
> >><br>
> >> So, leaving user with keyboard layout settings provided by kde if input<br>
> >> method<br>
> >> can already handle it doesn't make any sense.<br>
> >><br>
> >> Under upper idea, I wrote some code, now it's only complete the idea 1.<br>
> >> <a href="https://github.com/csslayer/**kde-input-method" target="_blank">https://github.com/csslayer/**kde-input-method</a><<a href="https://github.com/csslaye" target="_blank">https://github.com/csslaye</a><br>

> >> r/kde-input-method><br>
> >><br>
> >> Currently it only have fcitx's profile for test (since I'm selffish fcitx<br>
> >> dev), but it's trivial to add others (gcin, hime, ibus, maliit).<br>
> >><br>
> >> It provides distro independent start up and environment handling (by<br>
> >> global<br>
> >> kde env script), input method process starting and monitoring (by kded).<br>
> >><br>
> >> BTW kded part can be also adopted by plasma-active.<br>
> >><br>
> >> Configure button in kcm is not implemented yet.<br>
> >><br>
> >> Currently it has its own kcm, which I want to have it sit in<br>
> >> kcm-component-<br>
> >> chooser. And for backward compatibilty, it can be switch to "none" and in<br>
> >> that<br>
> >> way nothing will be affected.<br>
> >><br>
> >> And I need input from kcm-keyboard maintainer (already in CC) and non-CJK<br>
> >> people. I'm not sure about which list should be CC to, so I only send to<br>
> >> kde-<br>
> >> devel for now.<br>
> >><br>
> >> Regards,<br>
> >> Xuetian<br>
> ><br>
> > Hi<br>
> ><br>
> > I am a current (even if somewhat recently passive :)) KDE keyboard module<br>
> > maintainer and I promised Weng to reply so here it goes.<br>
> ><br>
> > 1. I've never used IM and have pretty vague understanding how it works so<br>
> > I am open for discussion<br>
> > 2. I don't plan to use IM (current keyboard layout implementation in KDE<br>
> > is good enough for me), but I don't mind to take a look at it if it's<br>
> > implemented as an additional feature and I can play with it temporarily to<br>
> > see if it bring something cool for users like me<br>
> > 3. There's probably tons of users that like me are ok (more or less -<br>
> > there's still open bugs) with current keyboard layout support in KDE and<br>
> > we<br>
> > *cannot* break things for them, especially not in 4.x branch (although I<br>
> > suspect people would prefer things they use not being broken in 5.x as<br>
> > well<br>
> ><br>
> > :))<br>
> ><br>
> > 4. There's tons of features requests implemented and bugs fixed in KDE<br>
> > keyboard module for last 10 years, this is the baggage I would not just<br>
> > trash<br>
> > 5. I have story of GNOME keyboard module maintainer leaving after dozen of<br>
> > years of development because keyboard layouts management code in GNOME was<br>
> > superseded by IM module<br>
> > 6. I have also stories that GNOME keyboard layouts got pretty much<br>
> > unusable for many users after this switch (unless you do the trick to<br>
> > activate old code)<br>
> > 7. Now having said that I also agree that many people need IM and also<br>
> > that keyboard layout module and IM are trying to do pretty much the same<br>
> > thing (at high level that is), so making them work together (or at least<br>
> > show up together for the user in UI) would be the right way to go;<br>
> > actually<br>
> > there's pretty old feature request (<br>
> > <a href="https://bugs.kde.org/show_bug.cgi?id=109845" target="_blank">https://bugs.kde.org/show_bug.cgi?id=109845</a>) to do exactly that<br>
> > 8. With 1-7 in mind I would say I am in favor of adding IM module to KDE,<br>
> ><br>
> > as long as:<br>
> >     a) it does not override, remove, or hide existing keyboard layout<br>
> ><br>
> > module<br>
> ><br>
> >     b) it is off by default (like keyboard layout module itself)<br>
> >     c) it makes sense that if IM is turned on, keyboard layout<br>
> ><br>
> > configuration (or to be exact some part of it) will be disabled (as it's<br>
> > functionality is taken over by IM)<br>
> ><br>
> >     d) as user needs to see which module (IM or keyboard layout) is<br>
> ><br>
> > active, the IM control UI should reside in the same UI as keyboard layout<br>
> > (I would suggest another tab), thus when user enables IM he can easily see<br>
> > which parts of keyboard module is taken over by IM and which he still can<br>
> > (or should) change<br>
> ><br>
> >     e) there's still some functionality from the old module that will be<br>
> ><br>
> > useful even if IM is active (i.e. xkb options to define keys behavior) -<br>
> > we<br>
> > need to analyze which parts are taken over by IM activation and which ones<br>
> > work in parallel<br>
> ><br>
> > I looked a bit at the code below at github and I don't see it doing<br>
> > anything special, if I understand it right it just allows to configure<br>
> > which IM module to use and pass some parameters, kded module then will<br>
> > take<br>
> > care of IM daemon/qt module activation. Somebody who uses and understands<br>
> > IM probably should try it to see if it works and if it does we can target<br>
> > this for 4.11 if we can meet criteria in 8.<br>
> ><br>
> > I'll update the bug 109845 to point to this conversation in case somebody<br>
> > there is still interested enough to get involved.<br>
> ><br>
> > Regards,<br>
> > Andriy<br>
> ><br>
> > P.S. adding kde-core-devel as even though it's not about core libs, it<br>
> > still about core KDE workspace functionality<br>
><br>
> I do have input methods enabled, so I have a few observations:<br>
><br>
> 1. Some input methods have a really nasty habit of taking over your<br>
> computer and can be hard if not impossible to turn off<br>
> 2. In practice there is little, if any, fundamental difference between the<br>
> two in principle from a user point of view<br>
><br>
> So I am 100% against making any input methods backend a hard dependency for<br>
> KDE.<br>
><br>
> My proposal would be the following:<br>
><br>
> 1. Keep the existing keyboard layout controls completely as-is.<br>
><br>
> 2. Have, as an optional dependency, input methods backends<br>
><br>
> 3. If an IM is installed, add its list of method to the existing list of<br>
> keyboard layouts.  It would not replace or remove any existing layouts, and<br>
> would probably not even be listed separately.  Users don't really need to<br>
> know or care if they are using a keyboard layout or IM.<br>
><br>
> 4. Under the hood, if an IM is selected it can handle setting the keyboard<br>
> layout to whatever it needs.  But the user should not need to know this is<br>
> happening.<br>
><br>
> 5. If the user switches to a non-IM keyboard layout the IM is switched off<br>
> and the existing layout system is used.<br>
><br>
> I think this would allow people to have full use of keyboard layouts and<br>
> IMs without requiring IMs or interfering with existing layouts.<br>
><br>
> However I don't know the underlying technology behind the IMs so this may<br>
> not be feasible.<br>
<br>
Ok, first make it clear.<br>
I didn't plan to replace current keyboard kcm/kded in kde completely. The only<br>
thing have relation with current keyboard part in KDE is, the layout<br>
configurtation/setting part.<br>
<br>
What I want is:<br>
1. a replacable module to select current input method framework, help user to<br>
start correct process with correct command and set correct environement. This<br>
part is functional but still WIP and sitting in the github link I post in the<br>
first mail.<br>
<br>
And make this to be in the default compoenent part, make it selectable for<br>
user, and obsolete those distro specific solution<br>
Named:<br>
<a href="http://packages.debian.org/sid/im-config" target="_blank">http://packages.debian.org/sid/im-config</a><br>
<a href="http://packages.debian.org/sid/im-switch" target="_blank">http://packages.debian.org/sid/im-switch</a><br>
<a href="http://code.google.com/p/imsettings/" target="_blank">http://code.google.com/p/imsettings/</a><br>
And I know opensuse have one but not sure about the package name.<br>
<br>
2.  IF and ONLY IF, the input method framework selected in the default<br>
component have the ability to control the keyboard layout (which is pre-<br>
defined in the input method framework profile), then disable the layout<br>
configuration in KDE.<br>
<br>
Current keyboard kcm have 3 part, model/speed, xkb layout, and xkb option. The<br>
only part should be hidden is the layout part, the IM actually only care about<br>
the layout part.<br>
<br>
And you can always set it to "None", can bring back everything we have in<br>
before KDE 4.10.<br>
<br>
We can default to None in KDE and let distro to change to what ever suitable<br>
for them.<br>
<br>
So, there is no hard dependency on anything, just some pre-defined<br>
configuration will sit in KDE.<br>
<br>
Hope upper explaination suppresses all the concern about function lost, answer<br>
is:<br>
Nothing will be lost, and user can easily go back to their old way if they<br>
want.<br>
<br>
And answer another question might be brought up:<br>
Why disable the layout part, instead of merging input method into it?<br>
I've been input method framework developer for years, and what I have learnt<br>
is, there is some knowledge (knowledge of application know what the current<br>
context is) only available in input method part, only input method can control<br>
it in the correct fine-grained level, and bring the correct user experience to<br>
user.<br>
<br>
Currently, the KDE layot can support "application", "window", "global", this<br>
is its limit, while what input method know is the "input context", which is<br>
totally invisible from any other part in the desktop. Give the whole freedom<br>
to input method to select layout is the only right way to go.<br>
<br>
Regards<br>
Xuetian</blockquote></div>