-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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.
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
Mute room feature #5731
Mute room feature #5731
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly lgtm. I focused mostly on just auditing hooks/effects and didn't dig very deep on the actual components or css. Made a few notes, biggest one I would change before shipping is moving the toggling of the actual mic state out of an effect since its pretty weird to have the UI dictating that.
@@ -69,8 +71,16 @@ export function useMicrophone(scene) { | |||
[mediaDevicesManager] | |||
); | |||
|
|||
useEffect(() => { | |||
if (canVoiceChat) { | |||
mediaDevicesManager.startMicShare({}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't seem right to tie the actual behavior of mic toggling to a react hook. That would mean if no UI happens to be showing the uses useMicrophone
this would not be toggled. Should just be handled outside of react land. Probably in MediaDevicesManager in the same spot we are toggling it off on permission changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is mostly because the useMicrophone
hook is used in MicSetupModal
and the audio popover as that's where we want to conditionally start the mic based on if the voice permission is enabled. I don't have a strong opinion about this but I've moved it back to ui-root
as a hook so we can still update the UI without relaying on the useMicrophone
hook.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having MicSetupModal have an effect that initially enables the mic makes sense, since that's part of what that screen does. But having it here means this ends up being what is re-enabling the mic in response to permission changes which seems wrong. MediaDeviceManager is what handles turning disabling it when permissions change, so I would think in the same spot it should also handle re-enabling it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two different things. One is mic sharing and another one is mic enabling. Mic sharing just triggers the sharing process and ask for permission if needed. Enabling pauses/resumes the producer so we are effectively sending voice data.
In ui-root
we are listening to voice permission updates to start sharing the mic during the different entry steps.
In the MediaDevicesManager
we are listening to voice permission updates to pause the mic producer and we rely on the user to manually resume it as it might be tricky if the voice permission is re-enabled by a moderator and that forces the user's mic to open.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, that makes sense. We should still probably move this effect out of useMicrophone
though, since if anything happens to be using it when a permission change happens its going to trigger, since it has canVoiceChat
as a dependency, and useCan
listens for permission change events.
|
||
NotifiablePermissions.forEach(perm => { | ||
if (APP.hub.member_permissions[perm] !== settings.member_permissions[perm]) { | ||
hubChannel.sendMessage({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason this isn't just part of hubChannel.updateHub(settings)
like the other settings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are not sending messages for room permissions updates so we need to manually send these permissions as messages so we also have all the added message info that ret adds to correctly visualize them in the chat. Let me know if I'm missing something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We send messages for other permission updates like "allow object spawning" and "allow drawing" no? Shouldn't this be the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now we don't send messages for room permissions although if we are doing it for chat/voice probably we should also do for the rest? Maybe that could be part of a follow-up PR as this is how it's in production right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah seems worth changing on the server side so this can be removed as a special case.
src/react-components/presence-log.js
Outdated
return <div className={classNames(presenceClasses)}>{this.props.entries.map(this.domForEntry)}</div>; | ||
} | ||
useEffect(() => { | ||
setLogEntries(entries.map(domForEntry)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whats the goal with this effect and logEntries state vs just using entries directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if I get this one. Entries is the raw message data, logEntries are the DOM elements processed via map.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. But why have an effect and state instead of mapping in render like we were doing before. In either case we still have to render whenever a new entry comes in, so this just seems like an added layer of indirection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yep, right, yes this is redundant. Removing.
src/react-components/presence-log.js
Outdated
} | ||
export function PresenceLog({ entries, preset, hubId, history, presences, onViewProfile, include, exclude, ...rest }) { | ||
const intl = useIntl(); | ||
const isMod = useCan("kick_users"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We seem to be mixing moderator and owner in a few places. Here we are checking of kick_user
permission as "mod" but in other spots related to this we are checking if they have the owner
role. Is that intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in our case we want the room owners to be the ones with voice/chat permissions so I've introduced a useRole
hook to check for owner permissions and add some consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be using useRole
then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did that in 9602625 maybe you are referring to some other one? I think I've moved all of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah must have been looking at old code.
e29fb94
to
c59050b
Compare
This features add support for room owners to disable/enable voice and chat for the rest of the users in a room from the room settings panel. In case voice/chat is disable this will only affect to users that are not room owners.
¡
Related Hubs-Foundation/reticulum#629