Complex text input in Plasma

[Martin Gräßlin]

Am 2017-04-06 22:18, schrieb Eike Hein:
> On 04/07/2017 04:58 AM, Weng Xuetian wrote:
>> gnome-shell's kimpanel equilvalent stuff is bundled in gnome-shell, 
>> which make
>> it be able to access the windows position. Input method server send 
>> the offset
>> received from client (which is not global), and the gnome-shell move 
>> the panel
>> to the (offset+current window location)
> 
> This seems to be roughly what Martin wants to do as well, except I 
> think
> he was probably envisioning the window being part of KWin somehow.

Yes GNOME Shell (Wayland compositor) and KWin (Wayland compositor) are 
the same layer in the stack.

> 
> My understanding is that it might be necessary to allow the IME to
> provide the UI however, since one-list-popup-fits-all may not be true
> across writing systems.
> 
> 
>> 4. Let input method server controls the keyboard layout (which layout 
>> to use)
>> Keyboard layout is nothing special comparing with input method. 
>> Nowadays,
>> modern input method framework are trying to take over all this stuff. 
>> This is
>> essential for users to get best experience if they use multiple input 
>> method.
>> Because there's a concept called "input context", which is not 
>> essentially
>> one-to-one map to the window.
> 
> I saw this one coming and it's the reason I originally spoke up in
> https://phabricator.kde.org/D5301 - there's ongoing work on bringing
> keyboard layout switching policies to kwin_wayland right now, in a
> system that isn't integrated with the input method systems. This
> shows the need for coordination.

Important note here: IM is not able to control the keyboard layout. That 
must be in the Wayland compositor.

> A downside with the "input method always on" approach can be
> performance: We don't want to send events through layers of IPC
> for input scenarios we don't want to.

This is just another reason to have it in KWin which would completely 
eliminate the IPC.
Also from a security perspective way better. There is no chance for an 
integration of a system where every key event is sent through an IPC. 
That wouldn't pass my security review.

> 
> 
> This reads on things like the work in D5301. Scenarios:
> 
> * If the input method is always on, then there maybe doesn't need
>   to be a fallback to complex, redundant policy systems in KWin.
> 
> * If the input method continues to be an optional add-on, then
>   KWin still needs those policy systems.
> 
> * The input method could be rearchitected to drive KWin's built-in
>   policy systems via public API.

I dislike all three options. The base keyboard layout handling must be 
in KWin. KWin has to control the IM stack, not the other way around.

I'm not giving away control over such fundamental aspects of the stack 
any more. I want that these things function correctly and I'm not 
trusting 3rd party software to do the right things. KWin can do the 
right thing in all situations. KWin is the only element in the stack 
having a global view: is the screen locked, is virtual keyboard on, is a 
fullscreen effect in place, is a popup menu open, is a game being 
played? Only KWin knows that. Only KWin can ensure that the right thing 
is done all the time.

Due to that: no chance for IM controlling part of our stack. We control 
the IM.

Cheers
Martin