From kde-devel Sat Jan 26 15:14:28 2013 From: Weng Xuetian Date: Sat, 26 Jan 2013 15:14:28 +0000 To: kde-devel Subject: Re: Input method integration for KDE 4.11 Message-Id: <32363880.Mf0vyNAImF () chakra-zenbook> X-MARC-Message: https://marc.info/?l=kde-devel&m=135921330315330 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============6202599641604921786==" --===============6202599641604921786== Content-Type: multipart/signed; boundary="nextPart7155414.NmIEdnqL3l"; micalg="pgp-sha1"; protocol="application/pgp-signature" Content-Transfer-Encoding: quoted-printable --nextPart7155414.NmIEdnqL3l Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Saturday 26 January 2013 13:03:29=EF=BC=8CTodd : > On Sat, Jan 26, 2013 at 3:41 AM, Andriy Rysin wrot= e: > > 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 ab= out it. > >>=20 > >> im-switch and im-config have bug so long time, and all of them are= distro > >> specific. > >>=20 > >> 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, > >>=20 > >> Now, more and more input method are taking care of keyboard layout= (which > >> means it would just conflict with kde's own keyboard layout settin= gs), > >> 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 someth= ing > >> similar > >> with qwerty, but if you're using a de layout, it will type some no= n-sense > >> character. > >>=20 > >> And idea is, input method have layout on its own, and should be ta= ke care > >> by > >> input method itself (if they can). > >>=20 > >> So, leaving user with keyboard layout settings provided by kde if = input > >> method > >> can already handle it doesn't make any sense. > >>=20 > >> Under upper idea, I wrote some code, now it's only complete the id= ea 1. > >> https://github.com/csslayer/**kde-input-method >> r/kde-input-method> > >>=20 > >> Currently it only have fcitx's profile for test (since I'm selffis= h fcitx > >> dev), but it's trivial to add others (gcin, hime, ibus, maliit). > >>=20 > >> It provides distro independent start up and environment handling (= by > >> global > >> kde env script), input method process starting and monitoring (by = kded). > >>=20 > >> BTW kded part can be also adopted by plasma-active. > >>=20 > >> Configure button in kcm is not implemented yet. > >>=20 > >> 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. > >>=20 > >> 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 s= end to > >> kde- > >> devel for now. > >>=20 > >> Regards, > >> Xuetian > >=20 > > Hi > >=20 > > I am a current (even if somewhat recently passive :)) KDE keyboard = module > > maintainer and I promised Weng to reply so here it goes. > >=20 > > 1. I've never used IM and have pretty vague understanding how it wo= rks so > > I am open for discussion > > 2. I don't plan to use IM (current keyboard layout implementation i= n 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 tempora= rily 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 KD= E and > > we > > *cannot* break things for them, especially not in 4.x branch (altho= ugh I > > suspect people would prefer things they use not being broken in 5.x= as > > well > >=20 > > :)) > >=20 > > 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 d= ozen of > > years of development because keyboard layouts management code in GN= OME 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 a= lso > > 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=3D109845) to do exactly that > > 8. With 1-7 in mind I would say I am in favor of adding IM module t= o KDE, > >=20 > > as long as: > > a) it does not override, remove, or hide existing keyboard layo= ut > >=20 > > module > >=20 > > b) it is off by default (like keyboard layout module itself) > > c) it makes sense that if IM is turned on, keyboard layout > >=20 > > configuration (or to be exact some part of it) will be disabled (as= it's > > functionality is taken over by IM) > >=20 > > d) as user needs to see which module (IM or keyboard layout) is= > >=20 > > 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 eas= ily see > > which parts of keyboard module is taken over by IM and which he sti= ll can > > (or should) change > >=20 > > e) there's still some functionality from the old module that wi= ll be > >=20 > > useful even if IM is active (i.e. xkb options to define keys behavi= or) - > > we > > need to analyze which parts are taken over by IM activation and whi= ch ones > > work in parallel > >=20 > > 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 config= ure > > which IM module to use and pass some parameters, kded module then w= ill > > take > > care of IM daemon/qt module activation. Somebody who uses and under= stands > > 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. > >=20 > > I'll update the bug 109845 to point to this conversation in case so= mebody > > there is still interested enough to get involved. > >=20 > > Regards, > > Andriy > >=20 > > P.S. adding kde-core-devel as even though it's not about core libs,= it > > still about core KDE workspace functionality >=20 > I do have input methods enabled, so I have a few observations: >=20 > 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 betwee= n the > two in principle from a user point of view >=20 > So I am 100% against making any input methods backend a hard dependen= cy for > KDE. >=20 > My proposal would be the following: >=20 > 1. Keep the existing keyboard layout controls completely as-is. >=20 > 2. Have, as an optional dependency, input methods backends >=20 > 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 layout= s, and > would probably not even be listed separately. Users don't really nee= d to > know or care if they are using a keyboard layout or IM. >=20 > 4. Under the hood, if an IM is selected it can handle setting the key= board > layout to whatever it needs. But the user should not need to know th= is is > happening. >=20 > 5. If the user switches to a non-IM keyboard layout the IM is switche= d off > and the existing layout system is used. >=20 > I think this would allow people to have full use of keyboard layouts = and > IMs without requiring IMs or interfering with existing layouts. >=20 > 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. T= he only=20 thing have relation with current keyboard part in KDE is, the layout=20= configurtation/setting part. What I want is: 1. a replacable module to select current input method framework, help u= ser to=20 start correct process with correct command and set correct environement= . This=20 part is functional but still WIP and sitting in the github link I post = in the=20 first mail. And make this to be in the default compoenent part, make it selectable = for=20 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=20= component have the ability to control the keyboard layout (which is pre= - defined in the input method framework profile), then disable the layout= =20 configuration in KDE. Current keyboard kcm have 3 part, model/speed, xkb layout, and xkb opti= on. The=20 only part should be hidden is the layout part, the IM actually only car= e about=20 the layout part. And you can always set it to "None", can bring back everything we have = in=20 before KDE 4.10. We can default to None in KDE and let distro to change to what ever sui= table=20 for them. So, there is no hard dependency on anything, just some pre-defined=20 configuration will sit in KDE. Hope upper explaination suppresses all the concern about function lost,= answer=20 is: Nothing will be lost, and user can easily go back to their old way if t= hey=20 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 l= earnt=20 is, there is some knowledge (knowledge of application know what the cur= rent=20 context is) only available in input method part, only input method can = control=20 it in the correct fine-grained level, and bring the correct user experi= ence to=20 user. Currently, the KDE layot can support "application", "window", "global",= this=20 is its limit, while what input method know is the "input context", whic= h is=20 totally invisible from any other part in the desktop. Give the whole fr= eedom=20 to input method to select layout is the only right way to go. Regards Xuetian --nextPart7155414.NmIEdnqL3l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAABAgAGBQJRA/LUAAoJEI6LiYy/JBL5IVoH/3yiCDaRzsPtHVk8VQOoirwE vm0hL1bSpxSwUsRijZnQaTPEbyvsT3zSkCdqCwExd3eGpZr15bWfKZvsh9uQDPxQ sX2H2s1k+J3mUFMG4gqnrwfgJ9btFmXhWteTZ6kRgn7yMkvBHNBKMh3iDtznVlyi rftbNqd8Gqy+jGQ9RIDXtO5j2zrR0CmBKQ9bcg1iZTIdK3zbPky9LMi/vB1mNIvG w7geqgOkK7YFG7by7749nE+gV7tqGTUZQV1MC0dBtFna6UteC1LZJHwKHG9j2GuI ep7++NwtRbNIUIKnyv+ZDsSwCasmsNsk85F4eUosds6WHQ/YcOc+2M3dSAl1/dY= =HmLP -----END PGP SIGNATURE----- --nextPart7155414.NmIEdnqL3l-- --===============6202599641604921786== 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 << --===============6202599641604921786==--