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