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
