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
