Complex text input in Plasma

[Takao Fujiwara]

On 04/07/17 14:13, Martin Gräßlin-san wrote:
> 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.

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.

Thanks,
Fujiwara

>
> Cheers
> Martin
>