[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] Address book integration
From:       Zack Rusin <zack () kde ! org>
Date:       2003-07-11 2:26:43
[Download RAW message or body]

On Thursday 10 July 2003 17:14, Martijn Klingens wrote:
> > I was wondering, what were the examples of some of the
> > Kopete-specific fields?
>
> Could be anything, really.
>
> Off the top of my head, everything but the UID, some might be
> candidates for storage in KABC, but for none this is sure:
>
> - The local nickname (not the display name of the entire meta
> contact) for each protocol.

ACK

> - AOL buddy icons (or MSN 6 when we support it), esp. when different
> or incompatible with KABC's images

I'd like to see those stored as logos actually. If one meta contact 
provides few protocols which have them then Kopete should prompt the 
user which one does he/she want to use as the primary buddy icon.

> - Custom away statuses

ACK

> - Extra fields that MSN allows for a contact like phone numbers

We store a list of phone numbers in kabc, the more the better ;)

> - GPG keys (though these REALLY belong in kabc and should be shared
> between Kopete and KMail).

Full ACK.

> - Groups a user is in (personally I'd prefer using the KABC groups,
> but I am not 100% everyone wants that and even less sure KABC
> supports all requirements that we have (like, in MSN a user can be in
> multiple groups at the same time, and while I detest the feature we
> have to support contact lists that have this).

kabc does support this, you can be in as many groups as you like, the 
addresspicker that I've put in libkdepim already supports this.

> - Whether or not to have feature X enabled for user Y (currently not
> supported but I would like to see that some day in the future for
> stuff like GPG so it's a toggle that can be per-user or per-group
> overridden). - The account preference order for contacting a user

Yeah, shouldn't be in kabc.

> Yup. Though I was thinking more along the lines of starting an
> external app with arguments and not using a plugin system to keep the
> amount of changes to Kit, Kopete, etc. minimal, but yes.

It would be simpler to have it as a service. Then at least you'd know 
for sure what apps support this.

Zack

-- 
PCMCIA - People Can't Memorise Computer Industry Acronyms
_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]