Tag Configuration object draft

[Thomas Brüderli]

Christian Mollekopf wrote:
> Hey,

Hello Christian

> Here's a draft for the Tag configuration object:
>
> configuration = element configuration {
>     attribute version { #Kolab XML Version },
>     element uid { value-uid },
>     element prodid { #Product ID },
>     element creation-date { #Creation date },
>     element last-modification-date { #Last modification date },
>     element type { #String },
>     configurationtype-fields
>   }
>
> type = "tag"
>
> configurationtype-fields = {
>    element name { #String },
>    element type { #String } ?,
>    element color { #Color } ?,
>    element iconName { #Icon } ?,
>    element priority { #Integer } ?,
>    element parent { #UID } ?,
>    element member {#UID } *
> }

Looks good to me.

> Description:
> * name: The name of the tag that is typically shown to the user. This string
> could be translated if deemed necessary.
> * type: The type of the tag that can be used to filter the tags. Similar to a
> mimetype. No type results in a generic, all purpose tag.
> * color/icon: for displaying the tag and for highlighting messages with the
> specified color.
> * priority: "importance" of the tag, a value from 1 to 100. Primary purpose is
> sorting in the UI.
> * parent: For future tag hierarchies (I could exclude this from the initial
> implementation).
> * member: A UID of a member of the tag.

For tagging email messages, I suppose the member { #UID } element will 
hold the according Message-ID header value, right?

> Kontact internally uses all of those, plus:
> * font/textcolor/backgroundcolor: for display purposes (messages with a tag or
> shown with the according font/textcolor/backgroundcolor). text/backgroundcolor
> replaces the single color above.

I think this can be substituted with some simple math that sets the text 
color to black or white depending on the 'color' value if that one is 
used as background color. We already have single color values for 
calendars and other resources and therefore should use the same concept 
for tags, too.

> * shortcut: A shortcut to set the tags (syncing those could result in conflicts
> though and is not necessarily relevant for all clients)
> * inToolbar: Boolean. If true an icon to set the tag is shown in the toolbar.

These two seem more client-specific and therefore don't need to be saved 
in a synchronized configuration object.

Thanks a lot!

~Thomas