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

List:       kopete-devel
Subject:    Re: [kopete-devel]  Discussion about metacontact,
From:       Olivier Goffart <ogoffart () kde ! org>
Date:       2005-06-15 11:53:33
Message-ID: 200506151353.36704.ogoffart () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Le Mercredi 15 Juin 2005 06:36, Duncan Mac-Vicar P. a écrit :
> Hi. I want to clean metacontact nickname/photo/sources a bit.
>
> Right now the semantics are a bit hard to follow.
>
> - Each metacontact has a Id, which can match a KABC contact [0]

ok

> - Each metacontact has a displayName [1]

ok

> - Each metacontact has a nameSource and photoSource, which are Contact *

ok

> - if those are NULL, then it uses the KABC (for photo) and [1] for the
> displayName. displayName is set to the KABC name when you make the
> association [0], but then you can set it to any custom value.

this one is hard to follow, others are fine.


I don't remember how displayName is synced with kabc, i think it is not.
IMO, it should


> These semantics are hard to follow, any change means setting sources to
> null to leave clear they are not source anymore, etc.

> One solution could be:
>
> - photoSource and nameSource are of type PropertySource (enum) which could
> be { Custom, KABC, Contact } [3]

ok

> - photoSourceContact and nameSourceContact are Contact* , and they
> represent the Contact source in case of [3] being Contact.

ok

> What to do with displayName ? it can return a display name depending of the
> source setting. However, setDisplayName has no semantic here, unless moved
> to setCustomDisplayName.


setDisplayName is used to change the displayname. If one call it, that mean 
the [3] becomes Custom or KABC


> Anyway, I don't know how to make this play with the properties system and I
> need advice here.


we could have the same system to merge every properties.  Anyway, i don't 
think it is needed in a first time.


In a second time (KDE 4?)  the kopete contaclist will be entirely placed in 
kabc.   This will considerably simplify the whole thing.  

currently we have
 KABC  -  MataContact -  subContacts  

we will have
  (KABC/MetaContact)  -  subcontacts



So, i don't think we should go for complex property system in KDE 3.5.  it's 
not the time to set up it.


[Attachment #5 (application/pgp-signature)]

_______________________________________________
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel


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