As I explained in Fedora 25, now the emoji typing is available in IBus panel menu.
ibus-1.5.15-8.fc26 is now available in koji or copr.
I moved the emoji function in IBusEngineSimple to a panel component.
The UI is designed to work as an extended IBus lookup window which can commit an emoji without mouse using Space, Enter and Arrow keys and expected to
be useful for both CLI and GUI users.
The shortcut key Ctrl-Shift-e is customizable with ibus-setup utility.
If this is comfortable for you, I'd like to implement the similar UI for gnome-shell.
Finally I'd also move the feature of Ctrl-Shift-u in GtkIMContextSimple to the emoji UI since the shortcut key is also not customizable.
https://desktopi18n.wordpress.com/2017/03/15/ibus-1-5-15-is-released/
Any feedback is welcome.
Thanks,
Fujiwara
On 07/11/16 21:41, Takao Fujiwara-san wrote:
On 07/11/16 20:25, Bastien Nocera-san wrote:
----- Original Message -----
On 07/08/16 20:41, Bastien Nocera-san wrote:
I think that the emoji input method should be a separate input method, so
that most users would have the choice between inputting using the keyboard
layout that matches their keyboard, and a separate input method for
emojis.
I think the emoji typing does not depend on XKB but is used frequently and I
don't think it should be separated.
It is on every other platform I can think of.
I don't think so.
I can see Emoji input on MS-IME in MS-Windows without switching engines in Japanese.
I can see Emoji input on Mac without switching engines with Command-Control-Space key.
I can see Emoji input on Xperia keyboard in Android without switching engines.
The IBus XKB engine is not discoverable (it's not listed in GNOME's Region
& Language settings) and the keyboard shortcut to input emojis is also not
discoverable. Having a separate input method is likely the better way to
implement this.
I replied this.
You haven't. You're implementing this without any regards for prior art and
design work that's been done. You certainly can implement this internally
however you want, but the end result has to match certain expectations, and
designs. Your implementation won't, and as a result won't be discoverable.
What do you mean in the certain expectations and designs.
As I explained, a radio button would be a idea to resolve your disacoverable way because I think you mean the GUI access.
Fujiwara
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
