Emoticon theme specification Version 0.1

[Frans Englich]

On Sunday 09 January 2005 13:02, Olivier Goffart wrote:
> Hello,
> My first mail was maybe too fast sent.
> I've tried to explain more in this mail.
>
> As many others instant messaging client, Kopete support emoticons.
> The user may choose, in the preference, a theme for emoticons. You may
> download some Kopete emoticons theme on the internet (kde-look.org)
>
> Recently, Konversation (an IRC client) added support for emoticons. They
> decided to use the same emoticon theme format as Kopete. so theme that
> might be found on kde-look works also for Konversation.
> Even KMail plan to do the same.
>
> The actual format is two years old.  It's a package containing all
> emoticons picture + an xml file giving each picture his ascii equivalent.
> themes are placed in $KDEDIR/share/emoticons
>
> It might be interesting to make a freedesktop specification for emoticon
> themes.  So any program (instent messaging, mail, newsgroup, ...) might use
> it.  And users will like to find more emoticons themes for their favorite
> application.
>
>
> I've specified it, the version 0.1 is there.
> http://kopete.kde.org/emoticons/emoticonspec.html
>
> As current implementation, there is already Kopete, which has it for more
> than two years.
>
>
>
> When it has been done, it has been planed to expand it later with some
> possible sounds tag. But this has finally never been done.
>
> Gaim themes has also the possibility to specify that an emoticon should
> appears only for a specified protocol.
> That specification doesn't have this, but if this is really wanted, it
> could be added.

As Owen thinks, I also see advantages in using the existing icon theme 
specification, if the complications can be solved. That spec have already 
outlined low level details for icon filenames/types, and hence avoids spec 
duplication, among other things.

One problem that to me seem to arise when piggy-backing the icon theme spec is 
the use of multiple emoticon themes. This can be solved by distributing XDG 
icon themes that only have emoticon icons, but inherits the preferred icon 
theme in general, and in this way "fakes" an emoticons-only icon theme. Would 
it be sufficient?

I think that the possibility of the ordinary icon theme to influence the 
emoticons has look/usability advantages; emoticons are part of the desktop as 
a whole, as the usage scenarios Oliver outlined.

As Owen mentions, emoticons also brings the problem of associating particular 
meta data with the icons, in this case what smilie an icon corresponds to and 
the "group"(anything else?). If that was encoded in the filenames, the icon 
names could look something like this, in line with the name standardization:

im-emoticon-<group>-<escaped smilie>

accompanied by predefined groups. 

The problem for the implementation to find out what icons that are available, 
as Owen described, could be solved by simply making the icons mandatory. 
Would that be too rude?

...however, that problem -- reverse mapping information from an icon -- exists 
in another case too: the pseudo icons concept. The idea of that is that 
icons' data files could contain IsAlso="foo;joe;" and then that icon would 
also correspond to the icons "foo" and "joe". The problem is it's of course 
impossible for the lookup code to go through all icon data files for each 
icon to be loaded -- some kind of mapping is necessary. The same dilemma 
applies for smilie->icon lookup, AFAICT.

Perhaps these two problems can be solved in one go. How this mapping is done, 
could be left to the implemention. One alternative is to create the mapping 
in the "icon theme cache mechanism"(a binary file hash, currently used in 
glib), which will be an appendix, optional part of the icon theme spec. KDE,  
could also implement it via ksycoca, I think.

When I prepared the draft for the icon name standardization[1](to be part of 
the icon theme spec, it standardizes icon _names_) I thought of emoticons. I 
didn't come up with anything else than cute because it needed more 
thinking(like what happens now), but I stumbled over this spec:

http://www.theoretic.com/Emoticons

I can't say anything useful about it currently, I think.


Cheers,

		Frans

1.
http://freedesktop.org/pipermail/xdg/2004-October/005084.html

The second draft, meaning tons of grunt work, is going _slow_ if you haven't 
noticed, due to financial issues(feel free to fix that particular bug for me, 
and I'll do the rest).