On Friday 15 June 2007 22:36:23 Matt Rogers wrote: > On Jun 14, 2007, at 8:32 PM, Gustavo Pichorim Boiko wrote: > > On Thursday 14 June 2007 22:02:17 Matt Rogers wrote: > >> On Jun 14, 2007, at 9:21 AM, Gustavo Pichorim Boiko wrote: > >>> 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. > >>> > >>> Ok, so I'm creating a branch work/kopete/identity_refactory to > >>> start working > >>> on this. The plan is: > >>> > >>> - Each account will belong to exactly one Identity. > >>> > >>> - Each identity can have one or more accounts associated to it. > >>> > >>> - Accounts can be moved from one identity to another > >>> > >>> - Properties (such as nickname/photo/personal info and so on) will > >>> be stored > >>> in the identity rather than the account. > >>> > >>> - Accounts should get/set properties from the identity rather than > >>> having > >>> their own properties. > >>> > >>> - Synchronization will be handle in the following way: > >>> * If you set a property in the identity, it will be applied to > >>> all accounts > >>> belonging to this identity > >>> * If a property changes server-side for one of the accounts in > >>> the identity, > >>> the user will be asked if he wants to have that property sync from > >>> server to > >>> the identity (and therefore to all other accounts), and, of course, > >>> provide > >>> the "Do not ask again" option. If there is only one account in the > >>> identity, > >>> do not ask and only apply the settings > >>> > >>> - The "Global Identity" will be a convenience for moving all > >>> accounts to a > >>> single identity (and maybe show an interface to unify the > >>> properties that are > >>> different in the old identities). The old identities will be > >>> removed (this > >>> can be discussed though). > >>> > >>> - The user info interface (the one I described in my proposal) will > >>> get/set > >>> properties from the identity, not from the contact > >>> > >>> - The property framework should (probably) be moved to the identity > >> > >> What do you mean by this? The property framework is needed at the > >> protocol level as level for the so-called private properties. > > > > Forget about this topic, I was missing the fact that the properties > > at the > > contact level are needed for, huh, contacts ;) > > > >>> - The Akonady support will probably be implemented on top of the > >>> identity > >> > >> huh? the akonadi support is about storing the contacts (at the very > >> least) from the protocols in the akonadi database and implementing > >> addressbook integration, etc. > > > > Ok, this topic was completelly wrong. > > > > After discussing a bit with Gof on IRC we got something interesting: > > We will move the property stuff to a class (named PropertyContainer or > > whatever better name someone suggests). > > > > This makes it possible to use it from Kopete::Identity (and from > > other places > > too) and it also make it possible to use the user info interface of my > > proposal on top of that. > > Can you expand on this? I don't understand what all is meant by the > above (PropertyContainer)
Yes, I wan to create a single interface for setting/displaying user information: this will use mainly the property(), hasProperty(), and setProperty() methods that were previously on Kopete::Contact. In order to have a single interface to view contacts' user info and identity user info, I have created a bas class PropertyContainer that both Kopete::Contact and Kopete::Identity will derive from. This enable me to call Kopete::UI::UserInfoDialog both for contacts and for identities. That's it :) The PropertyContainer (or it might have been called PropertyManager or something like that) will implement QList<Kopete::UI::InfoPage*> PropertyContainer::infoPages() returning all the information pages for the contact/identity. Derived contact classes may reimplement customInfoPages() to add protocol-specific user info to the dialog. (see the original proposal http://people.mandriva.com/~boiko/kopete/user_info/) This can be already seen in the identity_refactory branch on svn. 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
