A Wednesday 01 August 2007 12:17:51, Olivier Goffart escreveu: > 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
Yes, probably not much hard to do. > > 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 By accounts I mean the information on server. > When you change your data in the server with another client, the identity > should reflect that change next time you connect. I'm not that sure about this, mainly because you can change the server-side for more than one account from the identity, and when going to merge back you're going to get trouble on deciding from which account the info should be used. That's why I think that if the identity has more than one account assigned to it, its properties should have priority over the accounts specific ones. > The situation becomes even more difficult when you have two account in the > same identity, each with different things on the server. Well, that's my argument for using the identity info, simplify synchronization. > 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. Indeed. For metacontacts, the main problem is that it is the other side that decides which nickname and photo to use, but for identity, as we have control over that, we can simply define that all accounts belonging to an identity will be set up using identity properties. > > 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()] Well, I guess there were some FileEngine changes in trunk that should be double-checked in the identity (one more reason to merge the identity branch to trunk as soon as possible) > I also don't like the fact it's underlined. > > But it's just implementation details. Yes, this was the first thing that came up (and the easiest to implement in fact), but I'm open to other ideas. > > 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. I don't agree. The context menu is meant to do quick actions, and the general case is to set the status for all accounts at once, so no need to have the account as submenus. If one wants to set the status of an individual account, then he/she should do that in the identity widget. > > 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, ... +1 SVN is really bad at handling branches :( > - Everybody could easily help, specially protocol developers (if they still > exist :-s) Some still do. For ICQ and AIM I (hopefully) remember some of the implementation :) > - 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. Thanks :) And in fact I have to thank you for always providing quick feedback and helping me on understanding the details behind different parts of kopete. 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
