> On Nov. 9, 2011, 3:01 p.m., Pali Rohár wrote: > > Your patch disable updating nickname of all contacts from jabber server. > > This is bad because some people want to autoupdate new nicknames from > > server. > > Instead totally disabling this functions, it should be configurable (in > > jabber account settings dialog). > > Ralf Jung wrote: > Actually, Kopete already has a per-contact setting saying whether the > local or remote name should be used. The code should adhere to that setting. > > Btw, you filled the "Bugs" field in the request incorrectly. It must > contain just the bug ID, not the whole URL. > > Cyberbeat wrote: > I don't think, that I disable updating of nicknames of contacts from > jabber server. > > To explain the problem from the GUI perspective: > > - Right-Click a metacontact and choose its "properties" > - There you can choose, where to take it's displayname from, there are 3 > possibilities: > a) take displayname from adressebook (KABC) > b) take displayname from a protocol (you can choose, which) > c) define a custom displayname (which really should NEVER be overwritten > by some protocols!) > > The displayname for contacts should only be updated from server for case > b), which is the standard. > > For my test-contact I have chosen a custom displayname c) > This displayname is overwritten each time I connect to the jabber server. > This can be considered as a bug. > > > > More technically from the code perspective: > > In kopetemetacontact.cpp there is a method "displayName()", which is used > in the contact list, and which returns the displayname > from the configured ressource (a,b or c from above). Standard ressource > is b). > The member-variable "displayname" represents the "custom display name", > which is also only returned, if c) is the ressource. > > If I understood something wrong, please explain to me :-) > > Olivier Goffart wrote: > > b) take displayname from a protocol (you can choose, which) > > That is the nickname set by the contact himself (that is, for jabber, the > nickname in the vcard) > > > c) define a custom displayname (which really should NEVER be > overwritten by > > some protocols!) > > Yes it should. > This name should be synchronized with the name you chosen. > > > For my test-contact I have chosen a custom displayname c) > > This displayname is overwritten each time I connect to the jabber > server. > > This can be considered as a bug. > > When setting c), it should also write the displayname on the jabber > server. > If it do not, the bug is there. > > The rationale is that if you have two jabber clients, the name stay in > sync. > > > Cyberbeat wrote: > Thanks for the clarification. > > I didn't know that I could save my own custom nicknames on jabber server. > Is this a feature, every jabber server MUST implement? And, if not, > should the client get feedback, if saving was successfull? > > I think it is important now, to be sure, where the bug occurs: on kopete > or the server. Can someone with knowledge of XMPP give an answer? > > The server I talk about, is facebook. I know, that facebook only > implements parts of XMPP. And if facebook does not apply to the standard, > there are only two options for kopete: > > a) make an option for jabber like Pali suggests > b) clone XMPP protocol and adapt it for facebook > > I would prefer solution a) :-) > > But if facebook only does not support an optional feature and handles > things like the specification, then kopete should make its jabber protocol > implementation more robust. > > I think it is important to have good support for facebook, since I > believe, it is the (with great advance) most popular "xmpp" server, so > many people suffer from these problems. > > > Cyberbeat wrote: > Since noone answered for two weeks, I will go for solution a) without > being sure about my above questions. I really expect that that solution will > be accepted in principle, else please say stop _now_, because this will be a > lot of work. > > Cyberbeat wrote: > I have now looked a bit into the XMPP RFCs and the > kopete-xmpp-xml-console. What happens when I rename a contact: > > <iq type="set" id="af1ca"> > <query xmlns="jabber:iq:roster"> > <item name="mycontactsnewname" jid="-123123...@chat.facebook.com"> > <group>aaa</group> > </item> > </query> > </iq> > > <iq from="myn...@chat.facebook.com" type="error" > to="myn...@chat.facebook.com/Kopete_xxxxx" id="af1ca"> > <query xmlns="jabber:iq:roster"> > <item name="mycontactsnewname" jid="-123123...@chat.facebook.com"> > <group>aaa</group> > </item> > </query> > <error type="cancel" code="501"> > <feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> > </error> > </iq> > > So the server returns an error, which seems to be ok from the > specification. So now I think I can really consider the kopete behaviour as a > bug. > In its current state kopete should have had to deny the renaming of the > contact and display an error. > > So an option in xmpp config option like "Do you like your custom names > for your contacts be overwritten from the server?" yes/no like I plan to do, > seems to be a fine solution. > > Pali Rohár wrote: > Instead hacking this problem with config option it should be fixed in > jabber plugin / libiris library (return error when renaming failed)... > > As I understand your patch correctly, it only disable this code in > updateContact (which is called by jabber when contact on server has been > changed) > metaContact()->setDisplayName ( item.name () ); > > I think that updateContact() function should update only displayname of > *this KopeteContact (JabberBaseContact). Not metaContact()! > > Sorry for first info. Now I looked into jabber code and you are right. In > my opinion proper fix should be deleting lines 109-121. It is really not > needed, because kopete show displayname of metacontact from config dialog > (and here you can set my own string or displayname of attached contact). Can > you test if deleting these lines fix your problem and also if does not break > anything else? > > Cyberbeat wrote: > Since deleting the lines or adding "false" is semantically the same, I > can say, that I had no problems with this. > > What makes me now thinking is: > > With jabber we seem to have an additional nickname-source, because > nickname can be a) the original contacts name, b) the custom name stored on > the server (which for example could also have been set from the same user but > from another client than kopete), and c) the local-kopete-custom-nickname. > > I as a (normal average) user thought about "custom nickname" always as a > local nickname. This thinking would not allow kopete to do anything special > with nicknames on the server from that meta-contacts-dialog. There is also > the possibility to open a "vcard" for jabber protocol, but I cannot edit that > for my facebook-contacts, and cannot even receive one for my other jabber > account's contacts (only one..). What does editing and saving of that do? > Would it be better, to use that jabber-specific dialog for custom nicknames? > > May I commit the deletion of the lines to trunk now? And maybe also for > 4.7 branch? Nontheless I wish someone else with more "normal" jabber > servers/contacts than me would test my patch. > > btw. next feature I plan for kopete is inline metacontacts-renaming (F2 > shortcut). > > Pali Rohár wrote: > If user set custom name for metacontact, kopete (or plugin) should try to > update this custom name on server too (if server support it). And if on > server was contact name changed, kopete should update that display name for > that contact (but not metacontact!). If metacontact was set to use display > name from that contact, kopete (not plugin!) will update it in visible > contact list too. > > I agree with deleting that lines in trunk. (Please update patch before > commiting). But not 4.7 - it is stable, so only bug fix changes - and this > patch change default behaviour of jabber protocol and some users may will > have problems... > > Olivier Goffart wrote: > I don't know if it is a feature they MUST support, but i think so. > In any case, considering how important is the facebook server, i think it > is worth workarounding the fact that the facebook server do not keep the name. > I don't know exactly how this can be done, a bit of reverse engeenering > should show what the server reply when Kopete tries to change the name of > contact. Else maybe doing a request to see if the name was changed. In the > worst case, check for "facebook.com" in the jid. > > Olivier Goffart wrote: > Ok, turns out my previous message was still pending in reviewboard for a > long time. > > Pali, the name of the contact in the jabber roster should be in sync with > the metacontact's display name (not contact display name) > The KopeteContact (jabberBaseContact)'s name is in sync with the jabber > nickname of the contact fetched from the vcard, or from the nickname > extention. > > In other word: the KopeteContact name is the nickname, chosen by the > contact himself, while the metacontact name is the name chosen by the user. > So if i connect from another computer using Kopete, the names should stay > in sync. > > The problem here is that the server do not support a very basic feature. > > So the lines must be disabled only if the server do not support updating > the names. > This should not be a config option, but automatically detected. (so in > practice it would be an option store in the config file, but not shown to the > user. That option would be turned when receiving the error from the jabber > server) > > > Cyberbeat wrote: > But what, if I have grouped several protocols per contact (isn't that the > main reason for "meta"-contacts? I do that for many of my contacts with up to > 3 protocols per contact..)? Then the jabber server is allowed to override my > custom name which I choosed for the contact for all these protocols? Why? I > don't see the logic there.
If you grouped contact from several accounts, if they are the same person, you want to group them under the same name. This remember a discussion in the xmpp standard list when someone tried to make an extention to the protocol for metacontact, thatit was not necessery, as client could just group contact with the same name together (hence the name bind the metacontact) Kopete 0.12 did that (grouping the contact with the same name under the same metacontact), but somehow now it does not do it anymore. The point is, yes, the jabber server is allowed to overide 'your' custom name that you choose, because in theory, that new name would be the one that you choose from another client, and thus just syncing (so if you change the name in your work computer, it also changes in your home computer) Now, the bug is that the facebook server do not support this feature, so a workaround must be made, but i don't think one should break the syncing for working servers. - Olivier ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6823/#review10461 ----------------------------------------------------------- On Nov. 24, 2011, 7:12 p.m., Cyberbeat wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6823/ > ----------------------------------------------------------- > > (Updated Nov. 24, 2011, 7:12 p.m.) > > > Review request for Kopete. > > > Description > ------- > > This patch fixes the bug, that the jabber protocol overwrites manually given > nicknames each time kopete connects. > > > This addresses bug 274175. > https://bugs.kde.org/show_bug.cgi?id=274175 > > > Diffs > ----- > > /trunk/KDE/kdenetwork/kopete/protocols/jabber/jabberbasecontact.cpp 1263246 > > Diff: http://svn.reviewboard.kde.org/r/6823/diff/diff > > > Testing > ------- > > I used kopete several weeks with icq, jabber, msn protocol together with my > patch, and did not notice any problems. The wrong behaviour is fixed. > > > Thanks, > > Cyberbeat > >
_______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
