feat: make raid entry username clickable #5651
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| auto buildAndEmplaceMessage = [&builtMessages, | ||
| mirrored](MessageBuilder &builder) { | ||
| builder->flags.set(MessageFlag::Subscription); | ||
| if (mirrored) | ||
| { | ||
| builder->flags.set(MessageFlag::SharedMessage); | ||
| } | ||
|
|
||
| auto newMessage = builder.release(); | ||
| builtMessages.emplace_back(newMessage); | ||
| }; |
There was a problem hiding this comment.
Undo this change - leave the duplicate code.
The code, as is, would flag the raid message as a subscription message
There was a problem hiding this comment.
Are you wanting it to be duplicated so that the raid message isn't flagged as Subscription? I believe it should be as that's (currently) what dictates the background colour & highlighting.
If you'd rather it wasn't tagged as subscription, I'm more than happy to introduce some "event" (for lack of a better name) message type that has the same behaviour, but isn't tied to subscription bits (and isn't connected to subscription-related settings).
Otherwise, happy to revert this 👍
There was a problem hiding this comment.
I think it's still best to revert so we don't end up thinking it's correct. If it still requires the sub flag, leave the sub flag but just in its own place
There was a problem hiding this comment.
Re-inlined in afe3487
| auto loginTag = tags.find("login"); | ||
| auto displayNameTag = tags.find("msg-param-displayName"); |
There was a problem hiding this comment.
Since we don't care to make different implementation depending on if the value is unset, or if the value is set, or if the value is set but empty, instead of doing the v = tags.find("..."); v != tags.end(); dance, use tags.value("...").toString(), then check if the string is valid/non-empty instead.
Same goes for the color code, that way we don't need to blindly trust that it's a valid color, and keep the SystemColor if the color is invalid
We should keep the username colored, as the current implementation does. |
|
Retested on a92b5ee: |
|
I've duplicated raid message building logic to the non-RM path in d083c42 |
This PR aims to make the username of entering raid messages clickable using the `MentionElement". Did a bit of cleanup on the duplicated emplacement code which was shared by the path used by other system messages types.
I'm not sure how I feel about colouring the usernames with the user color - maybe it's better to colour them as
SystemMessageinstead?Example from a historical message:
