GNOME Bugzilla – Bug 789267
Add Insert->Emoji into message composer
Last modified: 2019-10-11 11:43:10 UTC
Using emoji would decrease message sizes, give a much wider range of pictograms, avoid issues with recipients whose clients are set to not display images, give visual consistency on the recipient's platform, and scale much better since they're not raster images. It would be good if Evolution could use GTK's new emoji picker for this as well.
Thanks for a bug report. You can enable to "Use Unicode characters for emoticons", but even then you cannot be 100% sure that each recipient will be able to see them properly on their system/browser/mail client/... Thus I'd not hurry with this.
Hi Milan, thanks, I had not seen that option, it's definitely useful! If that option is checked, it would be great if the composer switched to using the GTK emoji picker, since that will present a much wider range of emoji, instead of those preset in Evolution's smiley picker. It's true the recipient's client might not display emoji correctly either (so in that respect not really a better or worse situation than with embedded images), but modern platforms should not have issues (up-to-date Linux desktop environments, Windows 8+, recent Mac OS, Android, iPhone, modern browsers). Displayed properly: Emoji: sometimes (Text and HTML if modern Unicode support) Images: sometimes (HTML only if images enabled) Range: Emoji: >400 Images: 21 Email size (HTML, 5 smileys): Emoji: 5 kB Images: 13 kB No smileys: 5 kB Visually consistent on recipient's platform: Emoji: yes Images: no Scalable: Emoji: yes Images: no (fixed 16x16) There's an accessibility question as well (screen readers); I can't answer for certain on this, but I'm guessing this might be a win for emoji as well, since the plain-text rendering with "images" mode looks something like ":-):-D:-P:-DX-(". For HTML-mode (do screen readers normally use this?) presumably the screen reader would have to use the <img> tag's "data-name" attribute that Evolution assigns to the smiley images, or get the Content-Type name or Content-Disposition filename from the separate MIME part. In summary, it's 4 wins, 1 draw, and 1 either win or draw for emoji ;)
(In reply to Stephen from comment #2) > Displayed properly: > Images: sometimes (HTML only if images enabled) >... > Visually consistent on recipient's platform: > Images: no I do not agree with these statements. Those are HTML only but the images are attached in the message, which are (usually) always shown and they are consistent between platforms, because what you see you also send, thus it's seen on the receiving part as well. If you mean with the later that the recipient can use different "icon theme", then yes, that's true. > If that option is checked, it would be great if the composer switched to using > the GTK emoji picker, since that will present a much wider range of emoji, > instead of those preset in Evolution's smiley picker. I agree, that makes sense.
(In reply to Milan Crha from comment #3) > If you mean with the later that the recipient can use different "icon > theme", then yes, that's true. I mean the recipient will see consistency with other applications (including instant messaging) that use emoji on their computer (bearing in mind that the vast majority of recipients of emails from Evolution users are likely to be using either Windows, Mac, Android or iOS). This will also apply to more and more GNOME-using recipients as well I think, now that colour emoji support and a picker have landed in GNOME 3.26.
If you right-click in the Subject line box when writing a new email, there is an Insert Emoji option. It would be great if that would work in the body of the email too. Where does that body widget come from? Do we need to file a WebKitGTK+ bug? See also bug 790029.
It's a WebKitWebView in an editing mode (usually), yes. You can test with $ /usr/libexec/webkit2gtk-4.0/MiniBrowser --editor-mode which is not exactly the same thing, but it's close enough. It seem evolution overrides the context menu, which makes things to be done on the evo side.
I looked on this and realized that at least in gtk+ 3.22.26 the GtkEmojiChooser widget is a private widget, not public, thus there is no legitimate way to reuse it elsewhere than in gtk+ itself. There are options like trying to lookup for a symbol like gtk_emoji_chooser_new(), but it's not a good idea, because this API is undocumented, thus can change anytime without any notice. Maybe if you convince gtk+ developers to provide it as a public widget, then I'd add "Insert Emoji" into context menu and into Insert menu beside the Emoticons. I'm not going to replace the Emoticons with Emoji for sure (I think of interoperability with older systems).
Would you be interested in filing that GTK+ bug since you know what you are looking for?
(In reply to Jeremy Bicha from comment #8) > Would you be interested in filing that GTK+ bug since you know what you are > looking for? Sure, why not. https://gitlab.gnome.org/GNOME/gtk/issues/86
There doesn't seem to be much interest in publicize the GtkEmojiChooser popover, thus I took it from gtk+ and made a copy of it in Evolution. What a shame. This had been done also in WebkitGTK+ and since some version it shows emojis in better fonts/colors, thus it makes sense too. While the bellow change will need a bit of polishing (like better positioning of the popover, which I'd better do together with the JSC API usage), I'm committing it for the time being. Created commit 5a2f74f9e3 in evo master (3.35.2+)