[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Input method integration for KDE 4.11
From: Todd <toddrjen () gmail ! com>
Date: 2013-02-01 12:43:51
Message-ID: CAFpSVpKFFuobku12Yz5y3HR-6B4hx+V3DWe9najJOmfk_GpRPA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Jan 26, 2013 4:14 PM, "Weng Xuetian" <wengxt@gmail.com> wrote:
> On Saturday 26 January 2013 13:03:29=EF=BC=8CTodd :
> >
> > 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 o=
f
> > 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 an=
d
> > 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.
>
> 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 the=
y
> 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.
I don't really see how this answers the objection. I see two main options
here:
1. Have separate layout and IM guis, hiding the layout GUI if the IM is set
to "None".
2. Have a single layout/IM gui, and internally set the IM to "None" if a
layout is selected
I don't see why, from a programming standpoint, 2 is that much different
from 1. The IM backend would still see the same thing (either None or and
IM method), all that would change is that the user has one kcm to deal with
instead of two.
Think about it from a user perspective. Most users will have no clue what
the difference is between an input method and a layout, they just want
their keyboard to work. You have the layout set to None by default, which
means users will be faced with two completely different KCMs that, as far
the user is concerned, do pretty much exactly the same thing. How is a
user supposed to know what to do?
Also think about it from a support standpoint. Someone goes to, say, they
KDE forums, and they want to find out how to get their keyboard
configured. The user could have one of two completely different GUIs, or
both GUIs. This will vary both depending on which distro the user has and
which packages the user has installed.
This is not a hypothetical problem, it was a huge hassle on the forums when
openSUSE decided to rename "system settings" to "personal settings". Now
imagine that not only the name, but the entire layout of the settings
changes depending on the distro.
So I think that merging the two is the only practical option. It wouldn't
change anything about how the IM method is set, it would just hide those
details from the user.
[Attachment #5 (text/html)]
<div dir="ltr"><p dir="ltr">
On Jan 26, 2013 4:14 PM, "Weng Xuetian" <<a \
href="mailto:wengxt@gmail.com" target="_blank">wengxt@gmail.com</a>> wrote:<br> \
> On Saturday 26 January 2013 13:03:29，Todd :<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>
> 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.</p><p dir="ltr"><br> I don't really \
see how this answers the objection. I see two main options here:</p><p dir="ltr">1. \
Have separate layout and IM guis, hiding the layout GUI if the IM is set to \
"None".<br></p><p dir="ltr">2. Have a single layout/IM gui, and internally \
set the IM to "None" if a layout is selected</p>
<p>I don't see why, from a programming standpoint, 2 is that much different from \
1. The IM backend would still see the same thing (either None or and IM method), \
all that would change is that the user has one kcm to deal with instead of two.<br>
</p><p dir="ltr"></p><p>Think about it from a user perspective. Most users will \
have no clue what the difference is between an input method and a layout, they just \
want their keyboard to work. You have the layout set to None by default, which \
means users will be faced with two completely different KCMs that, as far the user is \
concerned, do pretty much exactly the same thing. How is a user supposed to know \
what to do?<br>
</p><p>Also think about it from a support standpoint. Someone goes to, say, they \
KDE forums, and they want to find out how to get their keyboard configured. The \
user could have one of two completely different GUIs, or both GUIs. This will vary \
both depending on which distro the user has and which packages the user has \
installed. <br>
</p><p>This is not a hypothetical problem, it was a huge hassle on the forums when \
openSUSE decided to rename "system settings" to "personal \
settings". Now imagine that not only the name, but the entire layout of the \
settings changes depending on the distro. <br>
</p><p>So I think that merging the two is the only practical option. It \
wouldn't change anything about how the IM method is set, it would just hide those \
details from the user.<br></p> </div>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic