From kde-devel Fri Feb 01 12:43:51 2013 From: Todd Date: Fri, 01 Feb 2013 12:43:51 +0000 To: kde-devel Subject: Re: Input method integration for KDE 4.11 Message-Id: X-MARC-Message: https://marc.info/?l=kde-devel&m=135972751322904 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============3493749689125278953==" --===============3493749689125278953== Content-Type: multipart/alternative; boundary=0015174c1da0a8bdb104d4a91987 --0015174c1da0a8bdb104d4a91987 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jan 26, 2013 4:14 PM, "Weng Xuetian" 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. --0015174c1da0a8bdb104d4a91987 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 yo= ur
> > computer and can be hard if not impossible to turn off
> > 2. In practice there is little, if any, fundamental difference be= tween the
> > two in principle from a user point of view
> >
> > So I am 100% against making any input methods backend a hard depe= ndency 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. =C2=A0It would not replace or remove any existi= ng layouts, and
> > would probably not even be listed separately. =C2=A0Users 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. =C2=A0But the user should not need t= o know this is
> > happening.
> >
> > 5. If the user switches to a non-IM keyboard layout the IM is swi= tched off
> > and the existing layout system is used.
> >
> > I think this would allow people to have full use of keyboard layo= uts 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.
>
> 2. =C2=A0IF and ONLY IF, the input method framework selected in the de= fault
> component have the ability to control the keyboard layout (which is pr= e-
> defined in the input method framework profile), then disable the layou= t
> configuration in KDE.
>
> Current keyboard kcm have 3 part, model/speed, xkb layout, and xkb opt= ion. The
> only part should be hidden is the layout part, the IM actually only ca= re about
> the layout part.
>
> And you can always set it to "None", can bring back everythi= ng we have in
> before KDE 4.10.
>
> We can default to None in KDE and let distro to change to what ever su= itable
> 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?<= br> > I've been input method framework developer for years, and what I h= ave learnt
> is, there is some knowledge (knowledge of application know what the cu= rrent
> 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 exper= ience to
> user.
>
> Currently, the KDE layot can support "application", "wi= ndow", "global", this
> is its limit, while what input method know is the "input context&= quot;, which is
> totally invisible from any other part in the desktop. Give the whole f= reedom
> to input method to select layout is the only right way to go.


I don't really see how this answers the objection.=C2=A0 I see two main= options here:

1. Have separate layout and IM guis, hidin= g the layout GUI if the IM is set to "None".

2. Have a single layout/IM gui, and internally set the IM to "None&q= uot; if a layout is selected

I don't see why, from a programming standpoint, 2 is that much diffe= rent from 1.=C2=A0 The IM backend would still see the same thing (either No= ne 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.=C2=A0 Mos= t users will have no clue what the difference is between an input method an= d a layout, they just want their keyboard to work.=C2=A0 You have the layou= t set to None by default, which means users will be faced with two complete= ly different KCMs that, as far the user is concerned, do pretty much exactl= y the same thing.=C2=A0 How is a user supposed to know what to do?

Also think about it from a support standpoint.=C2=A0 Someone goes to= , say, they KDE forums, and they want to find out how to get their keyboard= configured.=C2=A0 The user could have one of two completely different GUIs= , or both GUIs.=C2=A0 This will vary both depending on which distro the use= r has and which packages the user has installed.

This is not a hypothetical problem, it was a huge hassle on the foru= ms when openSUSE decided to rename "system settings" to "per= sonal settings".=C2=A0 Now imagine that not only the name, but the ent= ire layout of the settings changes depending on the distro.=C2=A0

So I think that merging the two is the only practical option.=C2=A0 = It wouldn't change anything about how the IM method is set, it would ju= st hide those details from the user.

--0015174c1da0a8bdb104d4a91987-- --===============3493749689125278953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============3493749689125278953==--