[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 4:16:45
Message-ID: 666b3e3b-a529-1ab8-8344-cb6e17ac96f9 () redhat ! com
[Download RAW message or body]

IBus emoji typing is updated day by day.
IBus 1.5.15 moved the emoji function in IBus XKB engine to IBus panel, which means \
the UI is now available from pane GUI menu and the shortcut key can  be customizable \
with ibus-setup: https://desktopi18n.wordpress.com/2017/03/15/ibus-1-5-15-is-released/


Also 'ibus emoji' CLI can launch the same GUI and it does not require to run \
ibus-daemon.

The emoji tying has two goals:
  - available with an extended lookup window likes an input method's lookup window \
                without mouse operations for input method users
  - available from panel menu by mouse only for GUI users

Thanks,
Fujiwara

On 04/07/17 05:18, Eike Hein-san wrote:
> 
> 
> 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
> 


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