Re: EB-lite emoticons (was Re: EB-lite feature requests)

"A. Craig West" <[email protected]>
Newsgroups gmane.network.everybuddy.user
Message-ID <[email protected]>
On Tue, 11 Mar 2003, Meredydd Luff wrote:

> Right. In fact, could you hold on a little bit with this? I'm not sure that 
> this is the right way to go about emoticons. Especially considering how we're 
> hoping for multiple UIs, we had some plans for common format for emoticon 
> themes. Current thinking has an archive (ZIP file? Directory?) with an index 
> file binding strings (eg ":-)") to filenames (eg "smile.gif"). This would 
> allow us to make more specific emoticon sets for specific protocols, 
> overriding the defaults with specified string bindings and images.

I was wondering if there was a good way to do this. I definitely agree that
making as much of the emoticon code as possible generic and server based would
be a good thing. Given a choice of formats, I tend to favour using .png files
or .xpm files. PNG probably has more support in non-unix environments, although
XPM is a nice text based format (and totally trivial to embed in the
executable, the file format is valid C code).
My smileyization has come to a temporary halt anyways, while I try to figure
out the QT Designer. So far, I've found it easier to edit the .ui file by hand,
but I haven't quite worked out the XPM.GZ format.
I'll go back to studying the requirements for making new clients, for now.
It looks like it should be possible to make a fairly generic client back-end
to handle the server communications, so that a person could write up the gui
part separately. The biggest problem would be doing it in a toolkit-agnostic
way. Seeing as I want to write a Java client, this wouldn't help me much
anyways, but for everybody else it would be a good thing...

-- 
Craig West         Ph: (416) 567-1491	|  It's not a bug,
[email protected]              	|  It's a feature...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.