Complex text input in Plasma

[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.

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.

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.

Just think it something similar, will kwin merge plasma? I don't think you 
really want to  that.

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.

In the real crazy world (just some random idea not really say it would be 
practical), I could implement a feature like: because Input method daemon 
knows that the text around the current cursor (which is allowed by the 
protocol actually), I can detect the language and switch the input method.

Input method itself is already a complex system. I used to have many ideas 
about how to manage layout and input method together.  https://
www.csslayer.info/wordpress/linux/rfc-a-new-solution-to-input-method-keyboard-
layout/ And that is complex, and not be able to clearly defined with simple 
configuration file or some combo box option.

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.