GNOME Bugzilla – Bug 755579
Easily insert emojis
Last modified: 2017-08-11 23:13:45 UTC
Inserting emojis is very complicated, I have to open my web browser, Go to google, type in Unicode emojis, find some site, then copy & paste it. Add a emoji button that I can click on that opens up a popover that conveniently let me insert common Unicode emojis. Like is easily done on Android in apps such as Hangouts, Kik and WhatsApp.
Oups, it looks like bugzilla doesn't like emoji either... Since my message seems to be lost, I'll repeat it here: > <facebook-ish emoji> I came to suggest the same feature <sunglass emoji> > @Moo Try using GNOME Characters, it makes the process a bit easier than googling for the icons :-)
Yeah, I can use GNOME Characters (except I don't have it right now, its in 3.18, I have 3.16). But it would be awesome with an emoji-button so that I have emojis at my fingertips, without having to switch applications and stuff and juggle copy paste.
Created attachment 357297 [details] [review] flatpak: Temporarily add fontconfig/cairo The versions included in the runtime don't have the recently added support for color emojis, so bundle them in the meantime in order to make use of all the colorful goodness right away ...
Created attachment 357298 [details] [review] flatpak: Include color emoji font We want emoji support to work, independently from what fonts the user has installed on their system. So simply bundle an appropriate font and make sure fontconfig picks it up correctly.
Created attachment 357299 [details] [review] data: Include Emoji definitions The file is imported from the (MIT-licensed) emoji.json[0] node module, which generates it from the emoji list published by the Unicode Consortium. [0] https://github.com/amio/emoji.json
Created attachment 357300 [details] [review] emojiPicker: Add a simple emoji picker Rejoice, pango, fontconfig and cairo now support color emojis. GTK+ should gain an emoji picker eventually, but in order to enjoy the colorful goodness right away, implement a simple picker ourselves in the meantime.
Created attachment 357301 [details] [review] entryArea: Include emoji picker Now that the platform supports color emoji, expose the newly added picker as secondary icon in the entry area to make it easy to insert emojis.
Created attachment 357302 [details] [review] app: Add keybinding to show emoji picker In order to make the newly added emoji picker more accessible, add a new keybinding for popping it up (if available).
Created attachment 357308 [details] [review] emojiPicker: Add a simple emoji picker Swap signal emission <-> popdown, to not delete existing text when inserting an emoji.
Created attachment 357309 [details] [review] entryArea: Include emoji picker Improve insertion handling. (FWIW, as patches are getting out of order, I'm updating the wip/fmuellner/emoji-picker branch as well)
Created attachment 357310 [details] [review] emojiPicker: Add a simple emoji picker Base section indicator on last child in row rather than first, so that the expected indicator gets selected when clicking on it.
Created attachment 357311 [details] [review] entryArea: Share a single emoji picker The emoji picker contains a lot of widgets, so it isn't exactly cheap to create; it's also based on static data that doesn't differ between rooms, so with a bit of extra book-keeping we can share a single picker between all rooms.
Even a basic picker with just the most common 10-20 emojis would be very appreciated. However, if the picker offers thousands of emojis then it would be useful with a search function. Also the UI could be implemented so that it can browse emojis by categories. This could be implemented using a GtkGrid inside a GtkNotebook.
(In reply to Moo from comment #14) > However, if the picker offers thousands of emojis then it would be useful > with a search function. How about *trying* the patch set? The patches follow the mockups in https://wiki.gnome.org/Design/OS/Emoji, so yes, there *is* a filter entry and there *are* sections ...
Emoji column count: - OS X: 6 (Characters), 7 (popover?) - Windows: 10 - EmojiHelper: 11 - Android (Gboard): 7 - GNOME (tentative design): 5 Perhaps consider increasing the column count from 5 to 7?
(In reply to Moo from comment #16) > - GNOME (tentative design): 5 Actual patch: 6 Seriously, can you actually *use* the patches before you comment on what you *think* they do?
(In reply to Florian Müllner from comment #17) > (In reply to Moo from comment #16) > > - GNOME (tentative design): 5 > > Actual patch: 6 > > Seriously, can you actually *use* the patches before you comment on what you > *think* they do? Sorry, I just looked at the screenshots at the link you provided. 6 seems to be a saner value and more close what other implementations do. Perhaps it ought to be 7 columns though?
Review of attachment 357297 [details] [review]: lgtm
Review of attachment 357298 [details] [review]: lgtm
Review of attachment 357299 [details] [review]: lgtm
Review of attachment 357310 [details] [review]: code works and genreally looks good to me (+ lapo's tweaks), just a few questions out of curiosity: is it the norm that the implementation of a class and the actual use of a class is separated into two different patch sets? ::: src/emojiPicker.js @@ +67,3 @@ + + _init: function(emojiData) { + this._name = emojiData.name; so I see that the smiley name is private in each Emoji object, but i can still search "cry" and find crying smileys? o.o @@ +125,3 @@ +}); + +let sections = { i only see sections used inside the EmojiPicker class so why do you prefer to keep it outside here?
Review of attachment 357309 [details] [review]: generally looks good. hmm, I'm noticing that if I write 'abcdefg', select only 'defg' and go to the emoji picker to select an emoji, then the whole entry to cleared. I was expecting that only the text I had selected was replaced with the emoji of my choosing.
Review of attachment 357302 [details] [review]: lgtm
Review of attachment 357311 [details] [review]: lgtm
Created attachment 357371 [details] [review] emojiPicker: Add a simple emoji picker (In reply to Bastian Ilsø from comment #22) > is it the norm that the implementation of a class and the actual use of a > class is separated into two different patch sets? No, not really. On the one hand, the picker itself is a big enough change to be self-contained, on the other hand the entry-area patch to use it is not - so this could really go either way. > ::: src/emojiPicker.js > @@ +67,3 @@ > + this._name = emojiData.name; > > so I see that the smiley name is private in each Emoji object, but i can > still search "cry" and find crying smileys? o.o Yup, the Emoji object has a public match() function that is used for filtering (and which uses a normalized version of the private _name property) :-) > i only see sections used inside the EmojiPicker class so why do you prefer > to keep it outside here? It looked a bit weird between all the widget-setup stuff, but you are right, putting it outside the class is odd too. I've moved it back inside ...
(In reply to Bastian Ilsø from comment #24) > generally looks good. hmm, I'm noticing that if I write 'abcdefg', select > only 'defg' and go to the emoji picker to select an emoji, then the whole > entry to cleared. I was expecting that only the text I had selected was > replaced with the emoji of my choosing. Was that with the flatpak? The patch versions from comment #10 and #11 should have addressed that.
Attachment 357297 [details] pushed as 163fe24 - flatpak: Temporarily add fontconfig/cairo Attachment 357298 [details] pushed as 3febd52 - flatpak: Include color emoji font Attachment 357299 [details] pushed as fda8c9a - data: Include Emoji definitions Attachment 357302 [details] pushed as c56c33a - app: Add keybinding to show emoji picker Attachment 357309 [details] pushed as 9c4eaeb - entryArea: Include emoji picker Attachment 357311 [details] pushed as 0bd7b89 - entryArea: Share a single emoji picker Attachment 357371 [details] pushed as 0396590 - emojiPicker: Add a simple emoji picker