Complex text input in Plasma

[Weng Xuetian]

On Friday, 7 April 2017 23:18:37 PDT，Martin Gräßlin wrote：
> Am 2017-04-08 01:04, schrieb Weng Xuetian:
> > On Friday, 7 April 2017 06:46:03 PDT，Martin Gräßlin wrote：
> > 
> >> Am 2017-04-07 07:56, schrieb Takao Fujiwara:
> >> >> Due to that: no chance for IM controlling part of our stack. We
> >> >> control the IM.
> >> > 
> >> > Probably I think this way would not work with IBus.
> >> > Each IBus IME are called by IBus dbus method. You hardly ask each IME
> >> > maintainer to change the protocol.
> >> > IBus daemon would be the controller of IBUs IMEs.
> >> 
> >> I think I need to describe in a better way how I envision the future
> >> architecture.
> >> 
> >> I want to have the IM daemon merged into the wayland compositor. So
> >> KWin
> >> would talk directly with the IM through library calls and the composed
> >> text would be sent from KWin to the application through the Wayland
> >> text-input protocol.
> >> 
> >> I want to eliminate the IPC between applications and IM daemon.
> >> 
> >> If we are going to touch this code we can strive for the best solution
> >> and not keep stuck on the approach used on X11. And yes that might
> >> need
> >> adjusting the IMEs. But they need to be adjusted anyway. We wouldn't
> >> have this discussion if it would just work on Wayland.
> >> 
> >> Cheers
> >> Martin
> > 
> > I'm sorry to point out this won't really works. The Xwayland client
> > will have
> > to use XIM anyway.
> 
> Let's please completely ignore the legacy world in the planning for the
> future. We setup the perfect world and then look how we can make
> Xwayland work. Even ignoring X11 might be an option as Wayland will now
> get a massive push thanks to Mir finally being dead.
> 
> > From security point of view, I'm ok if the daemon doesn't directly
> > connect to
> > application. But I don't want kwin to run the daemon within kwin's
> > process. It
> > would impose too much complication and I will not be comfortable about
> > that.
> 
> I don't mind the IM daemon being part of KWin.
> 
> > People will need to load certain concrete input method as a plugin, I
> > don't
> > think kwin itself want to include yet another plugin complex system to
> > be
> > running inside kwin.
> 
> I don't mind that either.
> 
> > Just think it something similar, will kwin merge plasma? I don't think
> > you
> > really want to  that.
> 
> Well we merged:
>   * kglobalaccel
>   * screenlocker
>   * keyboard kded
>   * virtual keyboard
>   * multi screen functionality
>   * Everything that X-Server does
>   * ...
> 
> No I wouldn't mind merging plasma if it would make sense and improve the
> overall experience. That's what I care for: offering the best possible
> and secure experience. If that requires merging yet another daemon I
> don't mind. There are no sacred cows to me. We are changing the complete
> architecture of the display management, so I don't have a problem with
> rethinking everything.
> 
> > So the best solution IMHO, is to let kwin to expose certain feature
> > that will
> > only be allowed to be accessed the im daemon that kwin starts, which
> > means
> > user any not arbitrary launch a daemon and do whatever they want. And
> > that IS
> > what current wayland's im protocol is doing.
> > 
> > Also, talking about the layout, I don't think you really want to write
> > the
> > layout control code. I have never seen a developer who only use
> > keyboard
> > layout stuff knows what kind of feature that input method could
> > achieve.
> 
> Please note that only the Wayland compositor is able to set the keyboard
> layout. That is a technical restriction of the Wayland protocol. So yes
> KWin must (!) manage the keyboard layout no matter what IM devs think
> about it. It just must be in KWin.
> 
> > Compositor should really give this kind of freedom to input method
> > daemon. It
> > doesn't expose extra security issue if you think about it. kwin would
> > just
> > works like a router that talks with input method via wayland protocol.
> > And
> > kwin will not talk with some random input method daemon that it
> > unprivileged.
> 
> I don't mind giving IM some freedom, but at the center of the
> interaction there is KWin.
> 
> So for me the requirements are:
>   * no key events are sent via DBus
>   * applications do not talk to IM daemon
>   * QT_IM_MODULE must not be used as that breaks virtual keyboard
> handling
>   * No IPC in the key event handling code of KWin
> 
> I don't mind whether the IM daemon is a separate process only KWin
> interacts with or a library KWin links. I think a library would be
> better as that removes the need for IPC and allows to directly involve
> the IM from keyboard handling code. Please compare in that point to
> kglobalaccel.
> 
> On X11 kglobalaccel only listens to the key events which would trigger
> the shortcut and it's restricted by things like keyboard grab. On
> Wayland KWin can send any key event through kglobalaccel as it's linked
> directly. This allows us to make way better decisions as we have a
> global view. We can decide whether right now a global shortcut makes
> sense or not and then not send it in.
> 
> Please note that I look at this from an absolute engineer perspective. I
> don't care how it was in the past and only look at how it should be in
> the future. Especially given that the situation on X11 is bad. I don't
> want users to have to configure anything. If we add this to KWin it will
> not be a fringe feature which users have to manually enable. It will be
> a core part of the offerings. It will mean that every distro will have
> to ship with IM enabled and configured by default. Just like we just
> pushed all distros to enable virtual keyboard by default. I'm not in
> this to slightly improve the situation, I'm aiming for the best solution
> and nothing which is not perfect for the user from both a security and a
> usability perspective in future is acceptable to me. The approach must
> just work, without having to specify plugins to load in Qt or in Gtk, it
> just must work OOTM. Just like we did with the virtual keyboard.
> 
> Cheers
> Martin

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.

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?).

And that is one important reason why people make things to be multi-process. 
So the memory space is protected. 

 IPC is not bad by itself, the insecure IPC is bad.

The only thing make it "insecure" in the old way is basically because dbus and 
X11 itself is not easy or not possible to achieve the secure configuration. X11 
allows you to monitor the event from everywhere, and by default, dbus will 
allows you to use dbus-monitor like stuff. (It is possible to achieve secure 
dbus, but let just leave that topic aside.) I'm totally fine if we don't need 
to use our customized im module to get the input method works. 

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.