Complex text input in Plasma

[Weng Xuetian]

On Sunday, 9 April 2017 00:38:06 PDT，Martin Gräßlin wrote：
> 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.
> > 
> > 30ms is almost the maximum time that I found it would be accepted by
> > the user.
> 
> It's too much already. 30 msec means 2 frames, that is something users
> already start to see.
> 
> > 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).
> > 
> >> > Also the "input method always on" idea is not saying that every single
> >> > key
> >> > will be send to input method, it just mean whenever user need type
> >> > text, it
> >> > will be forwarded to input method.
> >> > 
> >> > 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 that
> >> > ), no
> >> > one would run a im daemon inside the compositor. Are they all ignore
> >> > the ipc
> >> > overhead?
> >> 
> >> 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.
> > 
> > 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.
> > 
> > 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.
> 
> hehe, I think we can agree on not liking that interface ;-)
> 
> > 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.
> 
> 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 daemon 
itself without breaking the desktop (Except the crappy XIM Xlib implementation 
which is synchronous everywhere and will choke application on the certain 
function). Weston also has some watchdog stuff to monitor whether the im daemon 
is dead and restart it.

> 
> 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.
> 
> 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.
> 
> What we would need is implement support for zwp_input_method_v1 in
> KWayland, then add support for it in KWin.
> 
> Cheers
> Martin