Complex text input in Plasma

[Martin Gräßlin]

Am 2017-04-08 17:26, schrieb Weng Xuetian:
> 
> You're wrong about the QT_IM_MODULE stuff. To make application to use 
> the
> wayland protocol to type (text-input), the implementation must be done 
> with
> QT_IM_MODULE=wayland. I don't mind if it is set to certain application 
> but set
> it in general won't work. Also to have real virtual keyboard , you need 
> to let
> the input method daemon to provides a virtual keyboard implementation.

No you are wrong about that one :-) It might be that it used to be like 
that, but Wayland is the default if no QT_IM_MODULE is specified. See 
https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandintegration.cpp#n142

> 
> And also, merging more and more daemon into kwin is not always good 
> even from
> security point of view. The problem is, once it got merged, the whole 
> memory
> space is being exposed. Which means, if there's a single piece of code 
> is
> vulnerable, it will affect the whole compositor. We are not perfect 
> people, and
> that's why put more code together will make it more vulnerable to 
> attacker. If
> you consider that, your prevention of ptrace on kwin becomes nothing 
> and so
> does your effort to make kwin not loading some random plugin (prevent
> ld_preload and qt_plugins_path?).

The security of the system breaks with the weakest link. Whether the IM 
daemon is insecure by running standalone or inside KWin isn't a 
difference.

> So, my proposal to this will be:
> im daemon <-> kwin <-> application, and the communication is done with 
> some
> wayland protocol.
> 
> and imho that would be best option to all people. Here's the reason
> 
> Pros
> - less code to run within kwin process
> - less change needed to existing im daemon (we just need an extra 
> frontend)
> and kwin
> - no hard dependency
> 
> Cons:
> more ipc latency, but this only happens if user need to type.

The IPC latency is a huge problem here. If we want to have a good 
experience KWin needs to decide whether to send a key event to the IM 
daemon or through wl_keyboard interface to the application. This means 
possibly a roundtrip in the event handling code. This code is currently 
the most crucial part of KWin. It opens a can of worms if we go IPC 
there and given your suggestion it needs IPC.

And even if we handle it without roundtrip we run into timing issues.
Consider:
  * KWin gets key event
  * KWin decides it goes to IM for window foo
  * IM does something with it
  * window foo closes
  * IM sends the composed text for window foo to KWin

Now what? In case we would eliminate the IPC by making KWin link the IM 
module it becomes:

  * KWin gets key event
  * KWin decides it goes to IM for window foo
  * IM returns the composed text for window foo
  * KWin forwards the composed text to window foo
  * window foo closes

So from KWin perspective everything becomes cleaner if there is no IPC 
involved towards the IM daemon. In that case KWin needs to adjust way 
less as we don't need a dedicated protocol.

I understand your concerns with linking stuff and loading plugins but I 
don't share them. Yes I also see this as a problem but I think it's less 
of a problem than IPC in this crucial area.

Cheers
Martin