Command and basic UI for custom presence status messages. #412
Conversation
|
Can one of the admins verify this patch? |
| @@ -271,7 +271,22 @@ var commands = { | |||
| } | |||
| } | |||
| return reject(this.getUsage()); | |||
| }) | |||
| }), | |||
| status: new Command("status", "<online|offline|unavailable> [<status message>]", function(roomId, args) { | |||
There was a problem hiding this comment.
could do with an empty line here
|
ok to test |
Half-Shot
force-pushed
the
presence-status
branch
from
978f08a to
3dbb416
Compare
|
looks better. @ara4n: any comments on the UX? |
|
Bump? |
|
uh, i seem to have accidentally managed to miss this for months; sorry :( My concern here is whether the idea of custom presence states is actually how we want to do this in terms of the spec. It feels like the current online/idle/offline states have pretty well defined semantics, and are basically an enum (which may be internationalised etc. in future). Going and then using that field as a free-form string feels pretty wrong. Instead it feels like freeform status messages should be an orthogonal separate profile field of some kind. I am painfully aware that the spec says you can put custom statuses in presence, but I think this is probably a mistake that wasn't fully thought through at the time. @erikjohnston do you have thoughts on this (given you've been playing with both presence & profiles recently?) |
|
Is this made redundant by @turt2live's presence stuffs? |
|
no |
|
oh it has custom status stuff too, nvm |
|
I just remembered this PR exists and I'm wondering if it's worth resurrecting this on the basis that we still don't have a spec solution, and it's in use by bridges in the wild. |
|
@Half-Shot does this just do arbitrary messages for custom presence, or is it meant to be arbitrary states like "away" or "asleep"? |
|
@ara4n >does this just do arbitrary messages for custom presence, or is it meant to be arbitrary states like "away" or "asleep"? It's custom messages because I feel like if we want to restrict the messages to a subset for uniformity, it should be specced. |
|
@turt2live is this useful to you at all, if I were to clean it up and look at getting it merged? |
|
Not for my particular use case, sadly. It'd be good to see it landed independently, although I think presence is scheduled for a rethink. |
Which was the same reason this kinda stalled last time :/ Anyway, I've fixed this up as best I can without testing it. |
The eternal story of presence :( |
|
@Half-Shot Would it make sense to close this then, since the path to merging seems unclear at the moment? We can always re-open / recover the code in the future. |
|
@jryans Yes, although I'd like an issue opened to state that status_msg and the new experimental type are at odds in terms of UX (even if not the same thing technically). |
|
I filed element-hq/element-web#8029 to capture the UX conflicts between these two related features. Please edit or comment on the new issue as needed. |
To make a start on element-hq/element-web#1528, I've added the command /status to set yourself to one of the 3 states and to leave a custom message. This will only work if you are on the latest synapse develop right now due to a bug. I've left offline and unavaliable in there for the sake of having it there, but I believe synapse will always set you to online if you have any activity.
In addition, the MemberTiles will now display status_msg if it has been set alongside your presence state.
This requires matrix-org/matrix-js-sdk#167 in order to work. *Which has been merged :)Signed-off-by: Will Hunt will@half-shot.uk
Fixes https://github.com/vector-im/riot-web/issues/478
~ Travis