<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>