Le mercredi 1 août 2007, Gustavo Pichorim Boiko a écrit : > Hello [...] > As I don't know the protocol implementations, I need some help on that: any > place where user information is required should use the identity() now, by > doing identity()->property() to get a property value, and > identity()->setProperty() to set the value of a property in the identity.
This is indeed very dependent of the protocol. Currently, i think most of protocol do that mainly in the corresponding edit account dialog, but also in a slot connected in the account constructor to the signal Kopete::ContactList::self()->globalIdentityChanged > It is still undecided how to handle synchronization, but my idea is to > always use properties from the identity, never from the accounts themselves > (unless an identity has only one account assigned to it, this would allow > using the data from the account, but for all other cases, the identity data > has preference). The synchronization problem is mainly between identity and account's server. Not really between Kopete internals like you seems to think When you change your data in the server with another client, the identity should reflect that change next time you connect. The situation becomes even more difficult when you have two account in the same identity, each with different things on the server. The same problem occurs with the synchronization of the metacontact's name, with the contact's group, ... Currently the ways we tried to fix theses issues are still not 100% correct (added the fact that different developers have different points of view, and that it change at each version) What do others client do ? I think we need to agree on something and stay on it. > I have created a dialog for configuring identity properties (which is > accessible from the configuration dialog), but for chaning properties that > are offen changed (like photo, nickname and so), I have created a inplace > widget in kopete contact list window, which can be seen at: > http://people.mandriva.com/~boiko/kopete/identity/kopete_identity_status.pn >g Besides Bille not liking the underlined texts (which is something pretty > easy to fix), I would like to know your opinion about that. This is damn slow to appears here. I have a lot of messages like that in the console: libkopete: [virtual bool Kopete::FileEngine::open(QFlags<QIODevice::OpenModeFlag>)] return: false libkopete: [virtual Kopete::FileEngine::~FileEngine()] kopete-account-icon:Kopete%3A%3AProtocol:previewaccount.jpg libkopete: [Kopete::FileEngine::FileEngine(const QString&)] kopete-account-icon:Kopete%3A%3AProtocol:previewaccount.mng libkopete: [virtual bool Kopete::FileEngine::open(QFlags<QIODevice::OpenModeFlag>)] kopete-account-icon:Kopete%3A%3AProtocol:previewaccount.mng OpenMode( "ReadOnly" ) libkopete: [virtual bool Kopete::FileEngine::open(QFlags<QIODevice::OpenModeFlag>)] kopete-account-icon: account not found libkopete: [virtual bool Kopete::FileEngine::close()] I also don't like the fact it's underlined. But it's just implementation details. > The identity icons are shown in the status bar for now, and don't have > (yet) status overlay. I still think there must be a better way for showing > the available identities than using a small icon on the status bar, but > that is what I have for now :) > http://people.mandriva.com/~boiko/kopete/identity/identity_menu.png > The final version of the context menu won't have the accounts as submenus > (as the account individual options can be configured in the inplace > widget), it will only contain identity things, like configuring the > identity and setting its online status. I think one should keep accounts submenu. > Like said before, the work is being done on a separate branch. Now it is > time to decide if this is going to be on 4.0, or if we leave that for 4.1 > (giving us more time to better clean up our UI and doing bigger changes > like this, or the contact list, status manager, etc) Personaly, i think you should merge. Here are my reasons : - Working with branch in SVN is not nice. Problem may occurs when merging, it is harder to look or search in the history, ... - Everybody could easily help, specially protocol developers (if they still exist :-s) - The current Kopete still need lot of work to get stable enough for a release. specially in our UI, so better to work directly on that UI. Anyway, i think you are doing a good work, thank you. -- Gof
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
