Complex text input in Plasma

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

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.


Taking a step back, there's a couple of ways to go on the system
architecture. Right now, an input method system is kind of an
"after market add-on" - it's something you install only if you
need to, and if you do, it replaces parts of your system with its
own stuff.

Thoughts:

a) The "replaces part of your system with its own stuff" is what
gets us the unintegrated config mess, where your System Settings
becomes useless if the input method is around.

b) Historically a input method is used by non-Latin-based
   language users, but with Emoji input and things like word
   completion, this is changing.

I think a and b together mean that an input method is now better
positioned as a core dependency of the system, not a special case.

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



Cheers,
Eike