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
