To really fix bug #33048 we need to be able to do two things:
1. change your nickname in an XMPP MUC.
2. join an XMPP with a specific nickname.
I've implemented this using a method and a property:
Chan.I.Group.SetOwnNickname(s): simply sets your own nickname in the channel if the protocol supports it. The nickname is changed when SelfHandleChanged is fired. This fixes #1.
Conn.I.RoomNickname.DRAFT.DefaultNickname: s, rw: a DBus property connection manager property (so it can be persistent). This fixes #2 by having a global nickname that is used when you join rooms. If it's the empty string then gabble will make up the nickname like it's been doing for years.
Neither of these will fix the case of you wanting different nicknames for different XMPP MUCs which you want set when you join them. tbh I think we should fix that when/if we need to.
Alternatively, we could put this Conn.I.RoomNickname interface in gabble and gabble alone under extensions/? It wouldn't be so hard to migrate from that to an interface like this in tp-spec if/when it's necessary.
You're missing a flag on Group to say whether SetOwnNickname works, for starters.
I'll have a proper look tomorrow/Monday, and think about whether we can somehow avoid having yet another interface…
(In reply to comment #2)
> You're missing a flag on Group to say whether SetOwnNickname works, for
Oops, I forgot about this, done now.
Also I added a note about what happens if you set a nickname with bad characters in it.
+ <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+ Raised when the new nickname contains invalid characters
+ and has been rejected by the server.
It can be rejected by either the client or by the server.
For instance, maybe my server supports Unicode 6 while my client only supports Unicode 5, so my client might think that 👀 is not a valid character, even though my server would accept it; or vice-versa.
+ <p>If the CHANNEL_GROUP_FLAG_CAN_SET_OWN_NICKNAME flag is
+ set on the channel, request the user's channel-specific
+ nickname changes. This method is only available in group
+ chats where users can have room-specific nicknames, such as
Why is that in SHOUTY CASE? It should be something like “<code>Can_Set_Own_Nickname</code> flag is set in <tp:member-ref>GroupFlags</>”… And the second sentence is kind of redundant with the first. So maybe
“If the <code>Can_Set_Own_Nickname</code> flag is set in <tp:member-ref>GroupFlags</>—on protocols where users can have room-specific nicknames in chatrooms, such as XMPP—request the user's channel-specific nickname changes.”?
+ <p>An interface on connections which is used to specify a
+ default nickname to be used when joining group chats which
+ support channel-specific nicknames.</p>
This is back-to-front. “An interface, implemented on connections where the user can choose a different nickname for themselves in each group chat they join, to specify the user's default nickname in chat rooms.”
+ <p>If this property is empty, the CM MUST use an appropriate
+ nickname when joining channels which support room-specific
MUST + woolly terms like “appropriate” seems a weird juxtaposition.
+ <p>Note that changing this property will not affect any
+ currently open room channels which support channel-specific
+ nicknames. To do this, <tp:dbus-ref
+ <p>To ensure that all rooms which support channel-specific
+ nicknames have the same nickname, the <tp:dbus-ref
+ property should be changed by calling <tp:dbus-ref
But you just said that that property doesn't update existing nicknames.
+ <p>Note that if the change is a success then the user's self
+ handle in the channel will change as an existing handle cannot
+ change its meaning. As a result, success is notified by the
+ <tp:member-ref>SelfHandleChanged</tp:member-ref> signal being
The first sentence needs some punctuation.
It's kind of confusing that this interface refers throughout to “nickname” when it actually means the Group.SelfHandle property. (Which has no Group.SelfID relative, I notice.)
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/106.