On Wednesday 13 June 2007 12:30:34 Olivier Goffart wrote: > Le mercredi 13 juin 2007, Gustavo Pichorim Boiko a écrit : > > Hi > > > > After thinking a bit more about that subject, I've got to write a > > proposal on that subject. > > > > http://people.mandriva.com/~boiko/kopete/user_info/ > > From your page: > > One approach to simplify that would be to share a single identity across > > all protocols, but this does not fit in all cases (for example, in a > > jabber account used for work contacts, you might want to put a different > > photo than the one you would put in a personal account), and for the > > uncovered cases we still lack a solution. > > That's the point of having multiple identities. > > My idea of a identity is the same as a meta-contact. (or like a > meta-account) An Identity contains accounts like a meta-contact contains > contact. > > account that are in the same identity share all data. that include > nickname, photo, vcard, and even status and status messages. > by vcard i mean the "identity" card, basically the same as the one in kabc. > Identities would probably replace different accounts in the status bar. > > This is anyway just my utopia.
This is a good idea, and as a start, each account (when added) would be an identity by itself (meaning that if the user haven't choosen to add the new account to an existing identity. Every account must belong to exactly one identity. And by doing that, user information will be only configurable through the identity interface. This would be very nice in fact. We should only take care of not complicating the interface too much, keeping it simple should be a requirement. > I have not solved the problem of synchronisation Maybe akonadi could help on that. > > What I am proposing is to add as many properties as possible to the > > protocol-independent account layer (which would be Kopete::Account or > > Kopete::Contact, but probably the first). > > The existence of such properties could be queried > > It would be interesting if your "new widget" could be also be used for > showing contacts (and meta-contact) properties. That's why IMO property > should be at contact level (and they are already), and the existence of > properties could probably belong to Kopete::Protocol Yes, I talked to Will on IRC and it is a concensus that the same interface should be used to edit contacs and the personal user info. > > Shared Config Widget vs Custom Properties > > [...] > > Yes, that's good. > > > The visual representation > > [...] > > I'm not sure we should place that widget into the configure account page. > But place this in another dialog, like we already do in Jabber and AIM. I'm having some more ideas on that, probably an update to the first proposal will follow :) > The reason is that the editaccount is more for connection and preference. > Also, for most protocols, that information is stored in the server, and > then require to be connected (and then make no sens to put that widget when > adding a contact) But if you are editting the identity, that information can be sent to the server when the account gets connected. Even more, if you are adding an account to an existing identity at the account creation time, you will need to syncronize that when the account gets connected anyway. > It make sens to me to be able to show this widget also in the dialog of > contact information (and have theses dialog common either) indeed :) > About your blender-like idea, it is AFAIK not used in KDE, I don't know > why. It may be interesting. I was even thinking about proposing that to be used in some more places, but I wanted to use it somewhere as a proof of concept, and probably I will do this in kopete, if later we decide it is not a good idea, it can be replaced by something else, it is just the visual representation anyway. Many thanks for your input. I will send another message as soon as I have news on that. Cheers -- Gustavo Pichorim Boiko ----------------------------------- KDE Developer www.kde.org Mandriva Labs www.mandriva.com _______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
