Re: F25 Self Contained Change: IBus Emoji Typing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Probably I need to clarify some points.

nodejs-emojione is required by build only but not installation. ibus converts emoji.json in nodejs-emojione to a GHashTable during the package build.

The current plan is to integrate the CLI with Ctrl-Shift-u for Fedora 25 and the next plan is to move the implementation in IBus XKB engines to a modal dialog with GtkSearchBox which is called by both the shortcut key and IBus panel icon menu and the shortcut key will be customizable by gsettings or ibus-setup but I'm not sure if that next plan is on time for Fedora 25.

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
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux