[Pidgin] #14992: improve Emotion handling

Wed Mar 14 12:50:34 EDT 2012

#14992: improve Emotion handling
--------------------------+-------------------------------------------------
 Reporter:  calestyo      |     Owner:  rekkanoryo
     Type:  enhancement   |    Status:  new       
Component:  unclassified  |   Version:  2.10.2    
 Keywords:                |  
--------------------------+-------------------------------------------------
 Hi.

 This "bug" is probably not easily solvable, if at all.
 So I guess this ticket should rather serve as a record for ideas how to
 improve the situation.

 IMHO, currently the handling of emoticons/smileys/etc. is a big mess in
 all chat clients, not just pidgin.

 Most clients (especially the native clients for some chat protocols)
 provide far more, typically graphical or even animated emoticons thant the
 the simples ones like:
 :-)  :-(  :-O  O:-)  etc.

 Even for thee simple ones, there could be different interpretations, like
 :-O is typically "astonishment" but could also be just "open mouth".

 When you take the more complex emoticons like these from Yahoo:
 :-&  |-) etc.
 you have basically no idea what they mean, when you can't see the
 ("proprietary") graphical image/animation.

 Now, IMHO, the problems start:

 - The meaning/semantics of the short forms (e.g. :-&  |-) ) may change
 even upstream (and actually this already happened so often, just take
 Yahoo as an example).
 This is especially problematic for the history, but also when chatting to
 older clients (native or 3rd party) that haven't adapted yet

 - Even for the upstream images/animations it's quite often ambigous what
 they actually mean.

 - As there exist dozens of 3rd party clients like Pidgin, you can be quite
 sure that the person you chat with, doesn't have the same
 images/animations and the same set of emoticons for a given protocol.

 - There are now many ways of protocol interconnection (e.g. Jabber
 transports) and you do not necessarily know what protocol (and thus which
 emoticons) your contact uses.

 - Different [native] clients interpret the same emoticon codes (e.g. :-L )
 differently.

 - If we take the "original" images/animations from the native clients
 (Yahoo, AIM, Skype) we have likely license issue.

 What do we want?
 - The meaning of emoticons should be not ambiguous and well defined.
 - Compatibility with the native clients.
 - Even many years later, the meaning of emoticons in the logs should be
 clear from.

 I guess it's rather obvious that compatibility with the native clients is
 not reachable at all or only partially.

 What solutions do exist to make the meaning of emoticons unambiguous?
 - Unicode Emoticons
 Unicode has now a (though rather limited) block of Emoticons. Each one has
 a quite clear defined meaning like:
 U+1F632 ASTONISHED FACE
 Disadvantages are: Not all systems/protocols/native clients may support
 this.
 There aren't characters for all possible emoticons.

 - Textual representation
 Instead of b-( (which means "beaten up" or so in yahoo) on could use
 strings like "*beaten up*".
 This is not perfect, but the semantics are clear, and everybody on every
 system can at least read it.
 Textual representation could be a fallback for those cases where no
 Unicode character is available (yet).

 My idea at the moment is basically the following:
 I have a image/animation (e.g. astonished.gif) for all/most emoticons, a
 textual representation (e.g. *astonished*) for ALL emoticons, the
 corresponing Unicode character (e.g. 😲) if possible, zero to many
 shortcuts (e.g. :-O :-o :O :o) that I use during typing
 which would give me a pidgin theme line like:
 astonished.gif  *astonished*    😲       :-O     :-o     :O      :o

 The short cuts should be just used when writing, they should neither be
 transferred, nor be stored in the logs.
 When it comes to logs or transmission to your contacts, then either the
 Unicode character should be sent (if available) or the textual
 representation (as fallback).