Input method integration for KDE 4.11

[Andriy Rysin]

If we're just adding, not replacing, I'm totally for adding IM module.
If that works well enough we can consider tighter integration to benefit
from IM advantages

Andriy
On Jan 26, 2013 10:14 AM, "Weng Xuetian" <wengxt at gmail.com> wrote:

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

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