Complex text input in Plasma

Sat Apr 8 06:18:37 UTC 2017

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