Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Render display names of users and rooms according to the spec - take 2 #4

Merged
merged 9 commits into from
May 3, 2016
Merged

Render display names of users and rooms according to the spec - take 2 #4

merged 9 commits into from
May 3, 2016

Commits on May 2, 2016

  1. Supply more information with User::nameChanged signal

    @KitsuneRal
    KitsuneRal committed May 2, 2016
    Configuration menu
    Copy the full SHA
    fb45e26 View commit details
    Browse the repository at this point in the history

  2. Store left room members as well. 

    In particular, this will be needed to render room names according to the CS spec.
    @KitsuneRal
    KitsuneRal committed May 2, 2016
    Configuration menu
    Copy the full SHA
    107b6fc View commit details
    Browse the repository at this point in the history

  3. Deduplicated room check-and-creation code.

    @KitsuneRal
    KitsuneRal committed May 2, 2016
    Configuration menu
    Copy the full SHA
    d5bde8f View commit details
    Browse the repository at this point in the history

  4. Change the way room members are stored to the one recommended by the … 

    …CS spec.

According to section 11.2.2.3 of the CS spec, clients SHOULD follow a certain algorithm of making a non-ambiguous display name of a user in the room context. This algorithm implies checking whether other room members have the same display name. This commit prepares for implementation of the algorithm:

1. Use a hash map instead of a list to store room members. The external Room::users() API is kept intact.
2. Convenience CRUD methods are implemented to deal with the hash map.
3. An additional slot for user renaming is introduced (because renaming affects the hash map). Binding of actual signals is left for the next commit.
4. nullptr is the recommended representation of a null pointer since C++11. Use that and mandate compiler support of that.
    @KitsuneRal
    KitsuneRal committed May 2, 2016
    Configuration menu
    Copy the full SHA
    32b055f View commit details
    Browse the repository at this point in the history

  5. Mark read-only accessors in Room::Private as const.

    @KitsuneRal
    KitsuneRal committed May 2, 2016
    Configuration menu
    Copy the full SHA
    abfdced View commit details
    Browse the repository at this point in the history

  6. Introduced Room::roomMemberName(User*) that follows CS spec section 1… 

    …1.2.2.3
    @KitsuneRal
    KitsuneRal committed May 2, 2016
    Configuration menu
    Copy the full SHA
    0a3fab2 View commit details
    Browse the repository at this point in the history

  7. Calculate room displayname according to CS spec, with a new signal fi… 

    …red on a displayname update.

This changes the way displayname is supplied to a client application - instead of calculating immediately, displayname becomes a separate stored value that is refreshed with every change of the list of members, or the name, or the canonical alias. displaynameChanged signal is supplied to subscribe to these updates: in case of displaying a room in the roomlist a client should use this new signal instead of Room::namesChanged.
The displaname calculation algorithm is described in section 11.2.2.5 of the CS spec: https://matrix.org/docs/spec/r0.0.1/client_server.html#calculating-the-display-name-for-a-room
    @KitsuneRal
    KitsuneRal committed May 2, 2016
    Configuration menu
    Copy the full SHA
    a83eee7 View commit details
    Browse the repository at this point in the history

  8. Reworked room name calculation to get rid of do {} while (false) 

    (as requested at PR review)
    @KitsuneRal
    KitsuneRal committed May 2, 2016
    Configuration menu
    Copy the full SHA
    b36a9f3 View commit details
    Browse the repository at this point in the history

  9. Actually connect User::nameChanged to Room; make a new Room::memberRe… 

    …named signal, which clients should use in the room context.

Processing changes of user displaynames is tricky: we have to not only deal with the currently renamed user but also with its past and new namesakes which might change representation due to that renaming. So in the worst case a single User::nameChanged signal may lead to three Room::memberRenamed references (and 3 user displaynames updated in the UI, respectively). And the newly added users should be taken care of in a similar manner, of course.
    @KitsuneRal
    KitsuneRal committed May 2, 2016
    Configuration menu
    Copy the full SHA
    9a41511 View commit details
    Browse the repository at this point in the history