GNOME Bugzilla – Bug 692689
Be more compatible with Facebook emoticon codes
Last modified: 2018-05-22 15:58:23 UTC
In particular, while I like to think of <3 as a left neighborhood of 3, the general expectation for it is "love". I found a list that claims to be complete at http://calebbrown.id.au/blog/complete-list-facebook-chat-emoticons , so I added a few missing codes to existing smiles. I didn't find an equivalent in gnome-icon-theme for some of them, so I just skipped it, but I think at least (Y) and O.o are worth supporting. Adding Tux as <(") would be a nice touch. (The attached patch uses emblem-favorite for <3, but I'll file a bug for gnome-icon-theme to get a better name, in case some icon theme uses a star instead)
Created attachment 234596 [details] [review] Be more compatible with Facebook emoticon codes Since we support Facebook chat, and interoperate with the chat from the browser, we need to support roughly the same emoticon codes.
(In reply to comment #0) > (The attached patch uses emblem-favorite for <3, but I'll file a bug for > gnome-icon-theme to get a better name, in case some icon theme uses a star > instead) Did you fill this bug? We try to follow the freedesktop icon naming spec (http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html) so ideally the spec should be updated first.
Yes, it's bug 692690. The icon-naming-spec also does not seem to be very maintained, although I'll file a bug there if so is desired.
Created attachment 265901 [details] [review] EmpathySmileyManager: use the proper Unicode characters For emoticons that are part of the freedesktop icon spec and of Unicode 6.3, recognize the character and replace it with the icon. Also, prefer the unicode character to the older ASCII encoding. This ensures the maximum compatibility with Hangouts, and also looks nice on iOS/Android. If instead of Facebook, we want compatibility with Hangouts, this is what it takes. Note though that the Hangouts XMPP compatibility seems to translate some emoticons into the older ASCII format (but not all of them), although this is not documented anywhere. I guess the next step would be to drop the hardcoded names and old-style codes, and just go with full Unicode emojiis, possibly borrowing from some web source. PhantomOpenEmojiis looks nice and includes a good subset of them (more than gnome-icon-theme at least).
Review of attachment 265901 [details] [review]: ++ please merge to master
(In reply to comment #4) > I guess the next step would be to drop the hardcoded names and > old-style codes, and just go with full Unicode emojiis, possibly > borrowing from some web source. PhantomOpenEmojiis looks nice > and includes a good subset of them (more than gnome-icon-theme > at least). Or maybe we could integrate those directly into gnome-icon-theme so they would be available to any GNOME app?
Attachment 234596 [details] pushed as 1d7db69 - Be more compatible with Facebook emoticon codes Attachment 265901 [details] pushed as d531114 - EmpathySmileyManager: use the proper Unicode characters
Created attachment 278487 [details] [review] EmpathySmileyManager: add support for all Unicode 6.3 emoticons Import the table of emoticons from the gemoji project (BSD licensed, unlike the actual icons), and use it to look up icons in the form "face-%x", where %x is the unicode code point of the character, ("face-%x-%x" when combining characters are involved).
Created attachment 278488 [details] [review] EmpathySmileyManager: improve the trie to use a hash table for children If the trie grows in breadth rather than depth (as is the case for the over 700 emoticons using individual unicode characters), O(N) behavior for looking up a child is problematic. On the other hand, if only one or two children exists, we don't want to pay the memory and time overhead of a GHashTable. So have trie nodes implement both, and switch from the list to the table when the load grows over 10 children. The magic number was chosen considering that a GHashTable has always at least 8 nodes.
(In reply to comment #6) > (In reply to comment #4) > > I guess the next step would be to drop the hardcoded names and > > old-style codes, and just go with full Unicode emojiis, possibly > > borrowing from some web source. PhantomOpenEmojiis looks nice > > and includes a good subset of them (more than gnome-icon-theme > > at least). > > Or maybe we could integrate those directly into gnome-icon-theme so they would > be available to any GNOME app? There are several characters in Unicode that are emojis/emoticons, and I'm not sure they fit in gnome-icon-theme - ideally, we would support ARGB fonts and have these in our default fonts. Plus, we need someone to draw the icons in the first place...
-- 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/empathy/issues/639.