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.
If the engine should be enabled by default for any languages, I think it would make sense
that the XKB engines also enable emoji and switching engines
would be more cost than switching input modes.
Once this feature is implemented, the translatable annotations also can be implementable
for input method engines.
I think other platforms does not separate engines for emoji typing.
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.
----- Original Message -----
> On 07/08/16 19:54, Bastien Nocera-san wrote:
>> ----- Original Message -----
>>> Bastien Nocera <bnocera(a)redhat.com> さんはかきました:
>>>> Except that the way that you'll be implementing this means it's
>>>> 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
>>> Oh, sorry, I wrote mistakenly "typing booster" above, that was
>>> a typo. What Fujiwara San is implementing has nothing to do with typing
>>> booster, it is for the IBus XKB engine.
>> Same applies to the IBus XKB engine. This engine doesn't seem to be listed
>> in GNOME's Region and Language panel, the shortcut isn't discoverable,
>> UI for it doesn't match what users expect from their use of emoji on mobile
> If the implementaion will satisfy users, I also wish to implement to
> I agree the undiscoverable point should be considered later.
> Maybe a switching radio menu item is an idea?
> I don't wish the lookup table by default against the mobile.
> I'm not clarified that you pointed the UI which does not match mobile users.