Re: Icons

On Monday 26 July 2004 17:48, J.L. Coenders wrote:
> Hi,
> Another question: do you plan on adding (emot)icons to EB-lite?
Yes indeed!

If you (or anyone else for that matter) are thinking of helping out, I 
was thinking of having icons (all icons, including anything like custom 
icons for services, such as AIM's "phone" icon for mobile users - when 
we get around to OSCAR) existing in a namespace, from which they can be 
retrieved with a "get_stream".

The tricky thing is how to do icon themes and protocol-specific smileys, 
and make them coexist nicely. I can think of two approaches:

(1)	Old EB (now Ayttm) style: Each service has a set of emoticon 
definitions mapping symbol sequences to a name (eg ":)" --> "smile"). 
There is then a series of mappings, defined by the current icon theme, 
mapping names to image files (eg "smile" --> "default/smile.png").

The upside:	Icons look consistent, across all protocols, but you are 
never shown an icon which would not appear to a native user of that 
software at the other end.

The downside:	Protocol-specific icons stand out a mile, the names are 
inconsistent, so you're not shown quite the type of icon the other end 
is, and so on.

(2)	Service-local emoticons: Each icon is referred to by two pieces of 
information - the name of the icon, and the service. Mappings occur as 
before, and the "get_stream" has two parameters instead of one (service 
and name). If an icon cannot be found with that service name, other 
icons (from different services, and those with a service of "") are 
tried, and used instead, if there's a match.

The downside:	Themes must overlay each protocol's icons separately - 
either that, or do something kludgy and effectively turn this system 
into option #1 whenever a theme is loaded. In addition, because it's 
the core which makes these substitutions, the UI, which is presumably 
caching these images, could well end up caching several copies of a 
particular image - once when it was served up for MSN, once for AIM, 
and so on.


I'm sure there are more (I haven't even touched on the possibility of 
making the core do all these substitutions itself and just send an 
<image> tag, whose "src" could be used as a parameter to "get_stream", 
thereby killing all of our caching problems at once and centralising 
quite a bit of logic), please do suggest away.

As for me, I'm going to bed.

Meredydd