The code path for when all tiles can fit on screen was failing to realize that it could sometimes get by with fewer columns. This resulted in wasted space for 4 person calls at some window sizes.
We've gotten feedback that it's distracting whenever the same video is shown in two places on screen. This fixes the spotlight case by showing only the avatar of anyone who is already visible in the spotlight. It also makes sense to hide the speaking indicators in spotlight layouts, I think, because this information is redundant to the spotlight tile.
This is because our layouts for flat windows are good at adapting to both small width and small height, while our layouts for narrow windows aren't so good at adapting to a small height.
If you were the only one in the call, you could get a broken-looking view in which the local tile is shown in the spotlight, and it's also shown in the PiP. This is redundant.
Apparently Renovate doesn't really like it when you use a group: preset inside packageRules, instead of at the top level of the config. We do want to apply schedule:weekly only to the "all non-major dependencies" group though, so we need to write the group definition out by hand.
There were a couple of cases where the lack of margins after the new layout changes just looked odd. Specifically, when the header is hidden (as in embedded mode), there would be no margin at the top of the window. Also the floating tile would run directly up against the sides of the window.
Due to an oversight of mine, 2440037639 actually removed the ability to see the one-on-one layout on mobile. This restores mobile one-on-one calls to working order and also avoids showing the spotlight tile unless there are more than a few participants.
If no one had spoken yet, we were still showing the local user in the spotlight. We should instead eagerly switch to showing an arbitrary remote participant in this case.
* Add DeviceMute widget action `io.element.device_mute`.
This allows to send mute requests ("toWidget") and get the current mute state as a response.
And it will update the client about each change of mute states.
* review + better explanation
* review
* add comments
* use `useCallback`
