Complex text input in Plasma

[Takao Fujiwara]

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
>