Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Change icon when muted/deafened #3368
@davidebeatrici First of all, thanks for taking the time to bother with this. It is much appreciated.
The reason I suggested changing the user icon is because push to mute is the opposite of push to talk, which changes the icon itself.
Adding muted_pushtomute.svg to the right, along with the rest of the muted/deafened icons would also work, but it wouldn't be as obvious.
I didn't implement this myself, because aside from being completely unfamiliar with the codebase, I wasn't sure if changing the icon or adding a push to mute indicator for every user, despite it only being needed for the local one was deemed acceptable. After all, push to mute isn't transmitted to the server as far as I know.
Apologies for any inconvenience caused by this.
Mar 11, 2018
After using this patch a little more, there seems to be more UI inconsistency. The talking icon changes based on the mute and deafened state of the user, but only for the current user.
There is also duplicate user state information:
(Deafened is shown twice in the above image)
I propose the following: revert the changes to the user voice activity icon, and when push to mute is triggered, add the push to mute icon to the right hand column in the server tree.
Since the push-to-mute state is not sent to the server (see #2736), the client can't know if other users are using the function, meaning that we can show the icon only for the local user.
That breaks consistency, because the main icon changes for every user according to the talking state.
I think that @bontibon's proposal is the best we can do at the moment.
I am a little confused about what I understood as other users supposedly having the user icons change as well? But I don't see that in the snapshot.
I have to disagree.
We handle two, or arguably three kinds of user states.
One is temporary state, like talking and push to mute, (continuous transmission is a special case, making the temporary talking state the norm).
The other is persistent, announced state like muted (also serving as a kind of afk/busy indicator, showing intent of muting oneself to others), and deafened (showing intent and that the other user will not hear what we say).
Push to mute is not a persistent mute state. As it only persists as long as the button is pressed, it is a temporary state - the opposite of PTT.
Let's also consider the voice indication though. When we receive voice from another user, we show this by the same talk state as when we talk ourselves. For the user, ignoring networking, this is fine and consistent. The one who talks (and transmits) is in the talking state. Technically behind it are two things though, the own talking state indicating transmission, and others talking state indicating receiving voice.
As such, changing the user talking state for PTT and PTM, but nothing else seems consistent to me.
I don't think push-to-mute should be a talkstate.
In essence, push-to-mute is just a "cough button".
If you're transmitting voice, and you press it, your talk state should be "not talking".
Before we added the push-to-mute state to the tray icon, there was nothing to indicate that you were using push-to-mute.
Perhaps it was better that way -- the system tray would simply indicate "not talking". Then you would know you weren't transmitting.
Though if people think having an extra state to know that you're pressing it is the way to go, I don't mind.