From kde-panel-devel  Sun Apr 09 21:47:26 2017
From: Weng Xuetian <wengxt () gmail ! com>
Date: Sun, 09 Apr 2017 21:47:26 +0000
To: kde-panel-devel
Subject: Re: Complex text input in Plasma
Message-Id: <1511030.OoeEHSb3Jq () chakra-tp>
X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=149177446826455

On Sunday, 9 April 2017 00:38:06 PDT=EF=BC=8CMartin Gr=C3=A4=C3=9Flin wrote=
=EF=BC=9A
> Am 2017-04-09 03:49, schrieb Weng Xuetian:
> >> I don't want to base any decisions on 5 year old numbers. 30 msec
> >> would
> >> be bad, but if it is with modern hardware just 10 it wouldn't be that
> >> bad.
> >=20
> > 30ms is almost the maximum time that I found it would be accepted by
> > the user.
>=20
> It's too much already. 30 msec means 2 frames, that is something users
> already start to see.
>=20
> > But it also means that if it is ok, we could put more computation into
> > it to
> > achieve better result. Also, I do feel that synchronously wait for
> > input
> > method result would be bad. In our customized im module era, we are
> > also
> > moving to synchronous wait to key event processing result to
> > asynchronous. As
> > you said their exists same problem, but overall it improves the
> > responsivieness when something does go wrong (when it's not a bug it
> > could be
> > memory or disk io).
> >=20
> >> > Also the "input method always on" idea is not saying that every sing=
le
> >> > key
> >> > will be send to input method, it just mean whenever user need type
> >> > text, it
> >> > will be forwarded to input method.
> >> >=20
> >> > I don't know whether I could persuade you, but please look around the
> >> > world,
> >> > iOS, android, sailfish (also use wayland), mac OS , (windows used to
> >> > run im
> >> > directly inside application.. but now they also have a service for t=
hat
> >> > ), no
> >> > one would run a im daemon inside the compositor. Are they all ignore
> >> > the ipc
> >> > overhead?
> >>=20
> >> I'm using sailfish and Android and both keyboards suck bad times.
> >> Sailfish is really bad, well it's maliit so no surprise there. With
> >> both
> >> systems I see problems in UI positioning because it's not in the
> >> compositor. Both don't feel perfect especially not in the "every frame
> >> perfect sense" we are aiming for on Wayland.
> >=20
> > But afterall, running fcitx as a library is possible since it is how it
> > is
> > implemented. Technically there's no such difficulty prevent us to do
> > so.  And I
> > have been using fcitx as a library for testing purpose.  But I guess
> > the story
> > is different for ibus, ibus is multi-process and its engine always
> > running in
> > different process, and it will always need to pass some ipc to its own
> > engine.
> >=20
> > On the bright side, I could bypass the ugly zwp_input_method_v1 and
> > directly
> > have zwp_text_input_v1 (or even unimplemented v2), I'd love to see
> > that.
>=20
> hehe, I think we can agree on not liking that interface ;-)
>=20
> > While there's still some hidden problem, the input method upgrade won't
> > be
> > easy since it's implmented via shared library (dlclose is dangerous
> > that I
> > always disable it via DL_NODELETE), I don't know if it would be
> > bothersome to
> > user or not, but luckily it's not something that will receive updates
> > everyday.
>=20
> Right it would mean session restart to upgrade. But even with dedicated
> IM daemon it would mean session restart.
As for this, not necessarily. Nowadays, it is totally fine to restart im da=
emon=20
itself without breaking the desktop (Except the crappy XIM Xlib implementat=
ion=20
which is synchronous everywhere and will choke application on the certain=20
function). Weston also has some watchdog stuff to monitor whether the im da=
emon=20
is dead and restart it.

>=20
> If we go for not shared library approach KWin would have to start the IM
> daemon and pass it a socket. Only the process started by KWin would be
> allowed to bind the zwp_input_method_v1 interface - or better said: only
> that process would be granted access to it. Given that upgrading would
> not be trivial either.
>=20
> Anyway going through the interface would be possible as well. It would
> require some special handling in KWin, but we do have comparable special
> handling for maliit for the Plasma phone.
>=20
> What we would need is implement support for zwp_input_method_v1 in
> KWayland, then add support for it in KWin.
>=20
> Cheers
> Martin