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