Empathy allows the user to edit the Alias and the ContactInfo in the same dialog. The problem is that in some CMs, one of the ContactInfo fields is actually mapped to the alias. So even though both of these fields can be set independantly, they result in the same property being set in the CM. This can result in surprising behavior. As discussed on IRC, we propose adding a ContactInfo flag that indicates that a particular field is overwritten when the user's nickname is set. irc transcript: <alsuren_> in http://telepathy.freedesktop.org/spec/Connection_Interface_Contact_Info.html#Contact_Info_Field I think we need to clarify what to do when the protocol uses fn as the alias <smcv> alsuren_: by which you mean "thing you set on yourself" not "thing you set on other people" I hope? alsuren_: Gabble has a similar but even nastier situation <smcv> alsuren_: older servers/clients use nickname if set, or fn our solution in Gabble was to just expose both nickname and fn in ContactInfo, and also whichever is set as the alias if you delete your fn *and* your nickname, you lose <jonner> smcv, my specific issue is e.g. in empathy's Edit->personal Information dialog there's an entry for both fullname and alias so if they both map to the same property, but the user sees them as two separate things, that's confusing. because they could set them to different values and they'd stomp on eachother. <smcv> jonner: hmm, I see what you mean <smcv> although I notice Empathy accidentally mitigates this by not showing nickname as editable... <jonner> hm, I don't have a nickname on my accounts, I guess. <smcv> maybe we need a ContactInfo flag for "this will be mangled if you change your alias" or maybe we should always exclude the "best" alias field, which would be NICKNAME on XMPP <jonner> smcv, yeah, my current solution was just going to be removing the alias-like field from ContactInfo but that's not entirely satisfactory <alsuren_> jonner: just been talking to smcv in person. I think we have a proposed change to the spec <jonner> nice. got a summary? <alsuren_> jonner: he'll burble at you in a minute, but adding a flag to Contact_Info_Field_Flags <jonner> ok <smcv> jonner: ok so my idea is jonner: define a flag whose semantics are "when you set your own nickname, this field will be changed as a side-effect" <alsuren_> I would guess also recommending that a UI which edits both should call SetContactInfo before SetAlias <smcv> then UIs like Empathy, which put alias and contact info in the same place, would hide that field but a UI that separated those functions would show it <jonner> right, hiding the field seems better than ordering the set. yeah <alsuren_> or that :P <smcv> something like Contact_Info_Field_Flag_Overwritten_By_Nickname which would typically appear on either FN or NICKNAME, or conceivably N if the protocol is extremely strange <jonner> how about CONTACT_INFO_IS_ALIAS_FOR_ALIAS ? :P <smcv> I don't want to call this "Alias" in the Names world, it's your nickname hyperlink it to both Account.Nickname and SetAliases
Created attachment 39182 [details] [review] ContactInfo: Add flag for fields that are overwritten by nickname It's likely that clients will want to expose the user's nickname and their contact info in the same place for editing. Howevever, many CMs map one of the ContactInfo fields to the user's nickname, so editing these two fields independantly at the same time results in surprising behavior. Adding a flag to the ContactInfo field will allow clients to hide these duplicate fields when presenting them together. Fixes: fd.o#30631
Comment on attachment 39182 [details] [review] ContactInfo: Add flag for fields that are overwritten by nickname uhh, I accidentally added this flag to Contact_Info_Flags instead of Contact_Info_Field_Flags, please ignore this patch.
Created attachment 39183 [details] [review] ContactInfo: Add flag for fields that are overwritten by nickname It's likely that clients will want to expose the user's nickname and their contact info in the same place for editing. Howevever, many CMs map one of the ContactInfo fields to the user's nickname, so editing these two fields independantly at the same time results in surprising behavior. Adding a flag to the ContactInfo field will allow clients to hide these duplicate fields when presenting them together. Fixes: fd.o#30631
Review of attachment 39183 [details] [review]: ::: spec/Connection_Interface_Contact_Info.xml @@ +473,3 @@ + + <tp:flag suffix="Overwritten_By_Nickname" value="2"> + <tp:docstring> Please set the XHTML xmlns on the <tp:docstring> and put the text in paragraphs, like so, to get better spacing in the HTML output: <p>Indicates ... this field</p> <tp:rationale> <p>If a client ... first.</p> </tp:rationale> You can abbreviate org.freedesktop.Telepathy to ofdT in namespace attributes. The actual text of this change looks fine, but I'd prefer it if you also said something like: <p>If used, this flag typically appears on either the "nickname" or "fn" field.</p> It also seems a good idea to recommend calling SetContactInfo *before* either calling SetAliases or setting the Nickname, if both were changed, so that it's harmless if the UI leaves the stale nickname in its "things to set" data structure. Hopefully we can rely on connection managers to handle overlapping edits correctly (Gabble does).
Created attachment 39187 [details] [review] ContactInfo: Add flag for fields that are overwritten by nickname It's likely that clients will want to expose the user's nickname and their contact info in the same place for editing. Howevever, many CMs map one of the ContactInfo fields to the user's nickname, so editing these two fields independantly at the same time results in surprising behavior. Adding a flag to the ContactInfo field will allow clients to hide these duplicate fields when presenting them together. Fixes: fd.o#30631
Review of attachment 39187 [details] [review]: (Sorry, I missed this for a while because the patch keyword was missing. Please add it when you want review on things.) The patch looks fine, please merge. ::: spec/Connection_Interface_Contact_Info.xml @@ +489,3 @@ + </tp:rationale> + <p>In addition to hiding this field when editing ContactInfo together + with the user's nickname, it is recommended that clients call Don't bother changing this now, but in future I'd prefer (the source code of) spec HTML to have a blank line between paragraphs, as seen here: <p>Something.</p> <p>Something else which you should imagine to be long enough to need wrapping.</p> <tp:rationale> <p>Because I said so.</p> </tp:rationale>
merged in a8f7f603bc1be3fd5ce66f01ec1ebf2b296f1a90 I'll remember to separate the paragraphs for next time.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.