[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Complex text input in Plasma
From:       Takao Fujiwara <tfujiwar () redhat ! com>
Date:       2017-04-07 5:56:54
Message-ID: 3eff3c5a-0f28-53dd-7f95-4e5127ad0246 () redhat ! com
[Download RAW message or body]

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
> 


[prev in list] [next in list] [prev in thread] [next in thread]