Because the height of our header component changed at some point, the hard-coded height values in the CSS were off by a few px and caused the page to overflow slightly.
This was a hack that we did back when we were working on PTT, to make the joining process for PTT more seamless, but it doesn't make much sense to auto-join normal calls without giving the user a chance to turn off / adjust their media. If we want this behavior back eventually, I think it would be better serviced by a separate URL parameter.
Splits out the room locartion parsing from everything else to avoid
one function that fills out different parts of its return struct
depending on its args.
… so that they use the 'on' state when muted, and announce the action that they take rather than the current state, as suggested in internal design guidance.
This attempts to converge all our modals on the new modal component while changing their designs as little as possible. This should reduce the bundle size a bit and make the app generally feel like it's converging on the new designs, even though individual modals still remain to be revamped.
They aren't yet used anywhere, but this will let us move on to implementing specific modal interactions from the new designs.
I made the design decision of making this new Modal component always be controlled by an explicit open state, which was inspired by some work I did with Jetpack Compose recently, where I saw that this makes state management and the behavior of components so much more obvious.
Here, I've begun updating the styles of video tiles to match the new designs. Not yet updated: the local volume option is supposed to go inside an overflow menu now, but I haven't gotten to that yet.
To make the outlines on hovered / speaking tiles show up properly, I have to remove the usePageFocusStyle hack, which was preventing CSS outlines from being used for anything other than focus rings. I honestly can't tell what problem it was solving in the first place: focus rings still appear to behave as expected throughout the application.
I noticed that none of these buttons had accessible labels, which is obviously no good since they rely on icons alone to convey purpose when not focused.
We were manipulating the participant's mute state directly for some
reason, just for setting the mute state directly, which bypased the
mutestates hook.
As per comment, livekit mutates the object that's passed in, so
we ended up re-requesting the devices in the next render because we
effectively passed in different options.
This was causing an extra reconnect cycle when the call was first
joined because it thought the previous SFU config was valid. This was
probably causing some client to fail to connect at all.
As a first step towards adopting the Compound design system and the new Element Call designs, this pulls in Compound's color tokens and applies them to all existing components. I've tried to choose tokens based on the semantics of where they're used, but in some cases, where the new and old design systems differ in semantics, it was necessary to choose tokens based on their resulting color. These hacks can be removed as we implement more of the new designs.
There were a set of environment variables that we used for custom themes, but Compound has way too many design tokens for that approach to still be a good idea, so I decided to replace them all with a single environment variable that just lets you write arbitrary custom CSS.
Rather than the matrixRTC memberships. We're essentially trusting
LiveKit's view of weho is connected here, so we may as well include
the real names of anyone we don't think is a matrixRTC participant,
for whatever reason.
We'll always have matrix-widget-api as a dep through js-sdk so also
specifyin it ourselves just means we'll end up using a different version
when the js-sdk upgrade their copy and get wierd errors. We could add a
peerDependency if we really felt the need?
