Complex text input in Plasma

[Martin Gräßlin]

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.

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