Bug 33589

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
> starters.

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">
+          <tp:docstring>
+            Raised when the new nickname contains invalid characters
+            and has been rejected by the server.
+          </tp:docstring>
+        </tp:error>

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
+          XMPP.

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
+          nicknames.</p>

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

Why not?

+        <p>To ensure that all rooms which support channel-specific
+          nicknames have the same nickname, the <tp:dbus-ref
+          namespace="ofdT.Connection.Interface">RoomNickname.DRAFT.DefaultNickname</tp:dbus-ref>
+          property should be changed by calling <tp:dbus-ref
+          namespace="ofdT.Account">UpdateParameters</tp:dbus-ref>.</p>

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
+          emitted.</p>

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.