(In reply to Takao Fujiwara from comment #0)
>  - The emoji annotation works with English only

Translation of names is coming soon, if that's what you mean:
https://git.gnome.org/browse/gtk+/log/?h=wip/emoji/preview


(In reply to Takao Fujiwara from comment #0)
> And then my idea is to move all the feature to GNOME-Shell only and manage
> the shortcut keys and annotation languages with GNOME-Control-Center and
> removes Ctrl-Shift-[u|e] in GTK.

What about people who'd want to take advantage of GTK+'s support for emoji on Windows or macOS?

The IBus emojier implementation is here:
https://www.youtube.com/watch?v=F5yViKrEf4M

It's a small window not to hide the user's input context and works like an IME lookup window.

(In reply to Daniel Boles from comment #1)
> (In reply to Takao Fujiwara from comment #0)
> >  - The emoji annotation works with English only
> 
> Translation of names is coming soon, if that's what you mean:
> https://git.gnome.org/browse/gtk+/log/?h=wip/emoji/preview
> 
> 
> (In reply to Takao Fujiwara from comment #0)
> > And then my idea is to move all the feature to GNOME-Shell only and manage
> > the shortcut keys and annotation languages with GNOME-Control-Center and
> > removes Ctrl-Shift-[u|e] in GTK.
> 
> What about people who'd want to take advantage of GTK+'s support for emoji
> on Windows or macOS?

That's a good point.
How to select a language? I think the current locale is not the emoji language.
Also the language annotations are already available [1].

[1] http://www.unicode.org/repos/cldr/trunk/common/annotations/

(In reply to Takao Fujiwara from comment #3)
> Also the language annotations are already available [1].
> 
> [1] http://www.unicode.org/repos/cldr/trunk/common/annotations/

Indeed, using CLDR’s translations would be highly desirable from the translation teams’ point of view.

I think the current keybinding is a bit complicated and not customizable in GtkIMContextSimple.
Probably I think set_keybinding() and set_emoji_language() are needed if GtkIMContextSimple is used.

There's literally no reason to have key bindings as an application level API or a toolkit setting.

Personally, I don't think there's any reason whatsoever to have this as a customisable key binding either, but that's me; I see no value in letting users change these two standard key bindings for GTK+ applications, and only see downsides in terms of documentation and behaviour.

I'm fairly sure, though, that the IMContextSimple solution is a stop-gap in order to provide this functionality in GNOME 3.26, and should be used as a fallback in case the desktop input methods do not provide support for emojis. If IBus wants to take over the emoji input side, I'm sure we can figure something out.

I have been a bit torn about implementing this in the toolkit vs relying on system-provided input method support. In the end, I came down on adding it to GTK+, since it is not that hard, and it makes it easier to provide a consistent experience.

I am open to reconsidering whether input methods are the right approach for this - part of the reason why there is basically no direct api for the emoji chooser is to not tie our hands.

As for Ctrl-Shift-u/e - these are in the 'easter egg' section. I don't consider it a first-class solution for Emoji input, and I have regretted a bit that I added Ctrl-Shift-e in the first place. The completion support that is in the wip/matthiasc/emoji-picker branch now is a much better solution where frequent emoji input is needed.

I don't think making the shortcuts customizable would make anything better. I fact, I would consider customizable shortcuts as an argument against relying on input methods for this. The more you make it customizable, the less it can be a just-works-out-of-the-box solution.

Wrt to translations, as David pointed out, there's a branch that makes the names translatable. Reusing CLDR translations for this sounds like a good idea. Just a matter of working out the mechanics.

As for languages, I don't know what an "Emoji language" would be and why it should be different from your current locale. I don't see that as a useful concept. Can you explain ?

in any case, I'm glad to hear that you support emoji input without switching input methods. It never made sense to me as part of a particular input method (typing booster or anything else).

(In reply to Emmanuele Bassi (:ebassi) from comment #6)
> I'm fairly sure, though, that the IMContextSimple solution is a stop-gap in
> order to provide this functionality in GNOME 3.26, and should be used as a
> fallback in case the desktop input methods do not provide support for
> emojis. If IBus wants to take over the emoji input side, I'm sure we can
> figure something out.

Unfortunately I think the current fallback is not good with two reasons.

1. gtk_im_context_simple_filter_keypress() is the fallback if ibus_im_context_filter_keypress() does not treat the key events.

I removed both Ctrl-Shift-u and Ctrl-Shift-e in #IBusEngineSimple which is used in im-ibus.so GTK IM module.
And im-ibus.so bring backs the key events with gdk_event_put() in ibus/client/gtk3/ibusimcontext.c:_process_key_event_done().
And finally gtk_im_context_simple_filter_keypress() receives the key events:

+ Trace 237905

So even if im-ibus.so does not handle Ctrl-Shift-u, GtkIMConntextSimple is called finally and users cannot output typed chars until they type Escape key because GtkIMContextSimple's preedit is not shown on im-ibus.so

And I cannot close the Ctrl-Shift-u bug:
https://github.com/ibus/ibus/issues/1889

While I moved Ctrl-Shift-e from IBusEngineSimple to IBus GTK Panel, IBus will have a regression because GtkIMContextSimple now bind Ctrl-Shift-e too.


2. GtkIMContextSimple is used for non-IME users in GNOME-Shell.

GNOME-Shell has two type input sources of INPUT_SOURCE_TYPE_XKB and INPUT_SOURCE_TYPE_IBUS in gnome-shell/js/ui/status/keyboard.js
The XKB type uses GtkIMContextSimple by default if users does not add any IBUS types, e.g. "pinyin" or "hangul".
The XKB type uses IBusEngineSimple if users add one more than IBUS type.
It means the XKB type has the two behaviors and I think most European people would use GtkIMContextSimple since they don't need input methods.

If gnome-shell always use ibus only, the problem won't happen and I'm happy with it.

(In reply to Matthias Clasen from comment #7)
> I have been a bit torn about implementing this in the toolkit vs relying on
> system-provided input method support. In the end, I came down on adding it
> to GTK+, since it is not that hard, and it makes it easier to provide a
> consistent experience.

It's nice to see GTK have the strong tie with the emoji feature but probably I think there are pros and cons.
My understanding is the GTK applications need to set "show-emoji-icon" property in GtkEntry and it does not work with X11 applications.
If IBus can launch GtkEmojiChooser and receive the selected emoji, I think IBus can send it with IBus API.

> As for Ctrl-Shift-u/e - these are in the 'easter egg' section. I don't
> consider it a first-class solution for Emoji input, and I have regretted a
> bit that I added Ctrl-Shift-e in the first place. The completion support
> that is in the wip/matthiasc/emoji-picker branch now is a much better
> solution where frequent emoji input is needed.

It's nice. I tried demos/widget-factory/gtk4-widget-factory and tests/testentryicons.
I think there are some enhancements.
I'd use the both feature in GtkIMContextSimple and GtkEmojiChooser with CLI. Seems GtkEmojiChooser is launched by clicking the icon or right click menu. I don't know how to activate the icon so that can type Enter key on the icon.

Seem arrow keys only can be used to move the cursor.

Seems the default window size of testentryicon is too small to show whole the GtkEmojiChooser because it's based on the popup window?

Seems GTK uses emoji.json from EmojiOne. Now I'm thinking Unicode emoji-test.txt and CLDR en.xml are more useful:
 - emoji-test.txt has a better category and fully-qualified.
 - "smile" shows more candidates. "100", "united states" can shows the character. 
 
> I don't think making the shortcuts customizable would make anything better.
> I fact, I would consider customizable shortcuts as an argument against
> relying on input methods for this. The more you make it customizable, the
> less it can be a just-works-out-of-the-box solution.

But there are problems as I commented above. And I think the feature of C-S-u and C-S-e can be consolidated. I'm also thinking the next feature is to support to type Unicode names.

> Wrt to translations, as David pointed out, there's a branch that makes the
> names translatable. Reusing CLDR translations for this sounds like a good
> idea. Just a matter of working out the mechanics.

It might be possible to convert CLDR xml to po files before asking translators.

> As for languages, I don't know what an "Emoji language" would be and why it
> should be different from your current locale. I don't see that as a useful
> concept. Can you explain ?

I think some users can use English locale but typing is a different language. 
Also IBus uses a fallback logic in CLDR data. E.g. if sr_Latin.xml is selected, sr.xml and en.xml are also loaded. I think basically users like to use the both the main language and English.

(In reply to Takao Fujiwara from comment #10)
> Seems GtkEmojiChooser is launched by clicking the icon or right click menu.
> I don't know how to activate the icon so that can type Enter key on the icon.
>
> Seem arrow keys only can be used to move the cursor.

Yes, keynav to the icons in a GtkEntry is not possible.

The standard context menu key should work, though, to bring up the popup menu?

(In reply to Daniel Boles from comment #11)
> (In reply to Takao Fujiwara from comment #10)
> > Seems GtkEmojiChooser is launched by clicking the icon or right click menu.
> > I don't know how to activate the icon so that can type Enter key on the icon.
> >
> > Seem arrow keys only can be used to move the cursor.
> 
> Yes, keynav to the icons in a GtkEntry is not possible.
> 
> The standard context menu key should work, though, to bring up the popup
> menu?

Yeah, that's interesting but my laptop does not have Menu key.
If the key could be customized, it would be nice.
I cannot find the settings in `gnome-control-center keyboard` and `gnome-tweak-tool`. I think xmodmap does not work with XKB closely.

> users cannot output typed chars until they type Escape key because 
> GtkIMContextSimple's preedit is not shown on im-ibus.so

I think that is just a bug with how this 'context chaining' is handled in ibus. If it falls back to GtkIMContextSimple, it should make sure that the preedit is shown

> My understanding is the GTK applications need to set "show-emoji-icon" property
> in GtkEntry and it does not work with X11 applications.

show-emoji-icon controls whether the clickable icon is shown in the entry. The context menu item "Insert Emoji" is available regardless of that.

> Seems the default window size of testentryicon is too small to show whole the
> GtkEmojiChooser because it's based on the popup window?

That is a limitation of popovers under X. We can do better with Wayland.

> Seems GTK uses emoji.json from EmojiOne. Now I'm thinking Unicode
> emoji-test.txt and CLDR en.xml are more useful:

Thanks for the suggestion. We process the data from emoji.json into a more compact representation here: https://git.gnome.org/browse/gtk+/tree/gtk/emoji/convert-emoji.c 
Should be possible to adapt that to use other data sources, although the json was very convenient

> I think some users can use English locale but typing is a different language.
> Also IBus uses a fallback logic in CLDR data.

But how is language relevant for emoji selection at all ? Do you mean for search-by-name ?

(In reply to Matthias Clasen from comment #13)
> > Seems the default window size of testentryicon is too small to show whole the
> > GtkEmojiChooser because it's based on the popup window?
> 
> That is a limitation of popovers under X. We can do better with Wayland.

For that, see https://bugzilla.gnome.org/show_bug.cgi?id=786963


Incidentally, how about Windows or Quartz - do we know if they support Popovers outwith the parent window? If so, it could be good to take advantage of that.

(In reply to Matthias Clasen from comment #13)
> > users cannot output typed chars until they type Escape key because 
> > GtkIMContextSimple's preedit is not shown on im-ibus.so
> 
> I think that is just a bug with how this 'context chaining' is handled in
> ibus. If it falls back to GtkIMContextSimple, it should make sure that the
> preedit is shown

Thanks. I understood how to prevent from fallbacking to GtkIMContextSimple now.

Then the left issue is, gnome-shell uses GtkIMContextSimple as the primary XKB and binds Ctrl-Shift-[u|e] which are not customizable.

> > My understanding is the GTK applications need to set "show-emoji-icon" property
> > in GtkEntry and it does not work with X11 applications.
> 
> show-emoji-icon controls whether the clickable icon is shown in the entry.
> The context menu item "Insert Emoji" is available regardless of that.

I mean xterm does not use Gtk emoji feature directly. Maybe Firefox also does not use GtkEntry directly.
I'm thinking if IBus connect to GtkEmojiChooser, IBus can insert the selected emoji by GtkEmojiChooser and output on any text applications.

> > Seems the default window size of testentryicon is too small to show whole the
> > GtkEmojiChooser because it's based on the popup window?
> 
> That is a limitation of popovers under X. We can do better with Wayland.

OK, I understood it's a known issue.

> > Seems GTK uses emoji.json from EmojiOne. Now I'm thinking Unicode
> > emoji-test.txt and CLDR en.xml are more useful:
> 
> Thanks for the suggestion. We process the data from emoji.json into a more
> compact representation here:
> https://git.gnome.org/browse/gtk+/tree/gtk/emoji/convert-emoji.c 
> Should be possible to adapt that to use other data sources, although the
> json was very convenient

Yes, I think the available emoji annotations are a little in GTK and it would be great if the annotations could be enhanced.
Non-European people might like to use "noun" annotations rather than "adjective" annotations.

> > I think some users can use English locale but typing is a different language.
> > Also IBus uses a fallback logic in CLDR data.
> 
> But how is language relevant for emoji selection at all ? Do you mean for
> search-by-name ?

Yes, I mean emoji annotations in the GtkSearchEntry.
E.g. Myself type both "apple" and "りんご" by cases to search "

> E.g. Myself type both "apple" and "りんご" by cases to search "

Seems emoji chars are not supported on the bugzilla :(.
I also think each table element of emoji candidates can show the multi-language annotations so that I type those annotations next time.

I modified IBus engines not to send Ctrl-Shift-u to GtkIMContextSimple:
https://github.com/ibus/ibus/commit/bbfb3d738b9d61d1eb0658a9ce56e3cd8c111ac4

Do you have any ideas to use IBus engines for XKB input sources in gnome-shell by default?
I can modify IBus to meet GNOME's requests.

I think replacing typed out emojis like :-) via ctrl+shift+e is unecessary and it would be much more helpful for user to open the GtkEmojiChooser via ctrl+shift+e like there is a gloabl shortcut on macos for opening the emoji chooser. Furthermore of course it would be great to have this working on all text fields even those that are not Gtk (Electron, Qt,...) but that may be hard to implement, but it would implement a consistent pattern so users can expect to always open up the Emoji Chooser when pressing ctrl+shift+e.

Retitling this bug, as it ended up being a mailing-list discussion in a bug. I've filed the translation request at:
https://bugzilla.gnome.org/show_bug.cgi?id=789159

(In reply to Bastien Nocera from comment #19)
> Retitling this bug, as it ended up being a mailing-list discussion in a bug.
> I've filed the translation request at:
> https://bugzilla.gnome.org/show_bug.cgi?id=789159

PO file corresponds an English word to a translated one but the annotations are not only one correspondence and it would not be useful for the language annotations.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/892.