On 07/08/16 00:25, Mike FABIAN-san wrote:
> Bastien Nocera <bnocera(a)redhat.com> さんはかきました:
>> Re-send to the change owner
>> ----- Original Message -----
>>> = Proposed Self Contained Change: IBus Emoji Typing =
>>> Change owner(s):
>>> * Takao Fujiwara <tfujiwar [at] redhat [dot] com>
>>> The IBus core will provide the Emoji Unicode typing with the IBus XKB
>>> == Detailed Description ==
>>> IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and
>>> think the similar implementation for the Emoji typging. With IBus XKB
>>> Emoji typing will be provided with the Emoji annotations  following
>>> == Scope ==
>>> * Proposal owners:
>>> - IBus core provide the dictionary of the Emoji typing.
>>> - IBus XKB engines load the Emoji dictionary.
>>> * Other developers: N/A
>>> * Release engineering: N/A
>>> - List of deliverables: N/A
>>> * Policies and guidelines: N/A
>>> * Trademark approval: N/A
>>>  http://unicode.org/emoji/charts/index.html#col-annotations
>> Will this use:
> I don’t think so, it is supposed to work in all xkb engines of
> ibus-typing booster, this is not a seperate engine like ibus-uniemoji.
Sorry, I missed the email.
I expect to use emoji not to switch the IBus engines.
Actually ibus-anthy already implements emoji typing in Japanese.
This implementation enables emoji typing in English with any IBus XKB
I also evaluated ibus-uniemoji:
Now IBus XKB engine uses both en.xml for annotations and emoji.json for
categories and ascii aliases.
Except that the way that you'll be implementing this means it's completely
undiscoverable. I know no one other than those that already use an IBus
method to input a non-latin language that use things like typing booster.
A separate input method that's automatically added to the default list of
"keyboard layouts" would be much better suited to our use case, and matches
the way people are used to enter emojis on Android and iOS, with a separate