Richard, thanks for chiming in!
Note though that you replied to a mail from me, and while I probably still
have some credit due to past Kopete work, I am no longer a Kopete developer
anymore because of lack of time. In other words: I'm not necessarily voicing
the opinion of the Kopete developers. :)
On Thursday 02 November 2006 18:12, Richard Laager wrote:
> I don't really recall any discussion about this on gaim-devel, and a
> quick search through my archives yields nothing.
That's good, especially now that you're here too, because it means we're all
involved in the discussion basically from the start and have all information
available.
> 2) The XML smiley theme would allow us to have mouse-over descriptions
> for smileys.
I wonder what XML has to do with that though, probably specific for Gaim's
implementation?
> 4) A standardized smiley theme would increase the number of smiley
> themes accessible to users and make it easier on people (and distros, if
> any of them care about smileys) looking to create a smiley theme.
Yes!
> If you really want to go there, I'd suggest we do a definition for
> smiley themes, then a separate text -> markup format specification, so
> they can be implemented independently.
After writing my first reply this morning that thought had crossed my mind
too, and after sending the previous mail I have been pondering about that
again.
I am not sure yet. On the one hand it feels more natural to have this in a
separate file, also because e.g. KMail certainly doesn't want markup and only
emoticons.
On the other hand, there's a bit of overlap in the two, like in my example of
replacing "o O ( Some thought )" with a graphic. Even then the implementation
of a thought cloud will (technically) be massively different from a simple
smiley replacement.
All in all I tend to agree, but I have some fears that I'm overlooking
something important.
> If the text -> markup specification isn't excessively complex, I'd
> definitely be willing to extend the text replacement plugin to handle those
> cases, and use the new format we design for its data storage.
The two have slightly different purpose though, and from a user's point of
view I expect him to select a predefined markup replacement theme, but
*customize* the normal text replacement like hte -> the. Depending on your
implementation in Gaim you may want to put it in a second filter plugin
instead.
> > - consideration of KMail and possibly other apps who also use the themes
>
> I'm not a GNOME developer, but it looks like Evolution just has a few
> pre-defined smileys. If they decide to support the theme, I don't think
> we'll have a problem there. If anything, they can just have a special
> protocol like "e-mail" or something.
KMail is *already* using the emoticon themes, so unlike Evolution we have to
care about existing code here. Haven't thought about what support exactly is
needed, if any, but we definitely have to think about it.
Some more things that need thought and that I came up with after my previous
mail:
* Security. Make sure code injection is not possible, and no external URLs
will be fetched. Only relevant to the markup part, not the 'plain'
emoticons.
* Define how much of HTML is allowed in markup. Full (x)html will inevitably
lead to compatibility issues in presentation across IM clients because of
different rendering backends. Perhaps we should follow whatever rule is
already implicitly imposed by the Adium theming engine, as we have to
support that anyway.
* URLs in markup should be normalized somehow, so "angry.png" is not fetched
from $CWD, but instead from /usr/share/emoticon-themes/...
* The markup engine should be BiDi-aware, so RTL-locales like Hebrew and
Arabic work correctly, as well as bidirectional themes like iChat. This is
especially important for supporting stuff like thought clouds.
--
Martijn
You will soon meet a person who will play an important role in your life.
_______________________________________________
kopete-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kopete-devel
