On Thu, 2006-11-02 at 18:45 +0100, Martijn Klingens wrote: > > 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?
Yeah, our current implementation isn't very extensible. Extensible is
XMLs middle...err, first ;) name.
> * 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.
I think the complexity of all of these issues is a great reason that we
should worry about just smileys first, and then optionally worry about
markup later. :)
The theme format from the Gaim patch looks like this:
<theme version="1.0" name="Default" desc="Emoticons from each protocol's
official client." icon="smile.png" author="Various">
<protocol name="default">
<smiley hide="true">
<image>luke.png</image>
<desc>Luke</desc>
<code>C:-)</code>
<code>C:)</code>
</smiley>
...
</theme>
The current Kopete format, from my previous comment on that tracker
item, looks like this:
<messaging-emoticon-map>
<emoticon file="emblem-favorites">
<string>(L)</string>
<string>(l)</string>
</emoticon>
...
</messaging-emoticon-map>
I'd like to maintain as much compatibility with existing smiley themes
as possible. Since Gaim doesn't have an XML format, this means Kopete
wins by default.
We agree that we need a version.
I like the idea of dropping the extension and allowing the application
to resolve different possibilities at run-time. This would allow, for
example, shipping both .svg and .png, and allowing the application to
determine at run-time which it wants. I think we might want to suggest a
default format.
Therefore, what about something like this?
---
Begin Basis of Specification
An emoticon map package shall consist of an emoticon map definition and
one or more image files.
<messaging-emoticon-map version="2.0">
<emoticon protocol="msn" file="love" hidden="false">
<description xml:lang="en">A loving heart</description>
<string>(L)</string>
<string>(l)</string>
</emoticon>
...
</messaging-emoticon-map>
The version attribute is OPTIONAL, but MUST exist for version 2.0 (the
"new" format we're describing) or higher emotion maps. The lack of a
version attribute indicates a 1.0 emotion map (i.e. the existing Kopete
format). The format of the version number is MAJOR.MINOR. The major
number SHALL be increased when backwards compatibility is broken. In
other cases of format changes, such as the addition of optional
elements, the minor number shall be increased.
The OPTIONAL protocol attribute to the emoticon element specifies that
an emoticon applies to a specific protocol. If the attribute is
ommitted, the emoticon applies to all protocols. If two emoticons with
the same string exist, the following rules apply: 1) If the emoticons
apply to different protocols, they SHALL each be applied for the
respective protocol. 2) If one emoticon applies to a specific protocol,
and another applies to all protocols, the specific one SHALL override
the global for its protocol, and the global icon SHALL be used for all
other protocols. 3) If the emoticons are for the same protocol or are
both global, the map definition is invalid; applications SHOULD reject
such definitions.
The REQUIRED file attribute to the emoticon element describes a path,
relative to the emotion map file, to the name of image to be used for
this emotion. The application shall determine by file extensions which,
if any, of the available images of that name to use. The emoticon map
package SHOULD provide a .png file for each emoticon.
The OPTIONAL hidden attribute to the emoticon element provides a boolean
value indicating if the emotion SHOULD be hidden from the user, when
presenting a list of emoticon choices. If omitted, it defaults to false.
NOTE: It would be contradictory and useless to omit a <string> element
and specify hidden="true" at the same time. If a theme does this, the
hidden attribute takes precedence.
The OPTIONAL description element provides a textual description of the
emoticon, suitable for showing to the user (e.g. in a tooltip). The
description element SHOULD have an xml:lang attribute specifying the
language. Multiple description elements are permitted per emotion,
provided each has a unique language specified in xml:lang. The
application SHOULD display the closest (using normal rules for matching
languages and dialects) localized description to the user.
The OPTIONAL string element provides an automatic mapping between a
user-entered string and the emoticon. The application SHOULD apply these
mappings to both incoming and outgoing text. Emoticons without a string
MAY be presented to the user as options to send on protocols that allow
for custom emoticons, inline images, etc.
---
Clearly we'll need some list of protocols. I'd like to be consistent
with the Unified Logging Format work that was done this summer (which,
as a side note, I also need to work with folks to get that finished).
So, that means: AIM, Yahoo, MSN, IRC, XMPP, ICQ, GroupWise, Gadu-Gadu,
Zephyr, Meanwhile, and Napster. Following that list, we'd need to add
SIMPLE (or SIP) and QQ. Objections?
Also, I haven't addressed the actual archive format for bundles. Gaim
uses gzip-ed tarballs. What does Kopete use? Anyone know about KMail?
Obviously, gzip-ed tarballs are the easiest for me to support code-wise,
but I'd also be open to .zip format, since that's popular in document
formats these days.
The language in my first draft spec probably needs lots of loving, but I
think what I've described will meet Gaim's needs. How does that work for
Kopete? I intend to get some input from Adium as well, as I'd love to
see a format that they can use as well.
Richard
signature.asc
Description: This is a digitally signed message part
_______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
