...instead of monkey patching the console log objects. We use a logging
framework everywhere now (this fixes the times when we didn't...)
so there's not really a reason to do this the hacky way anymore.
This means that log lines now appear to come from whatever else is
intercepting the logger (eg. sentry) rather than rageshake.ts.
Opinions on this welcome on whether it's better or not.
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.
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.
To track media devices, we were previously relying on a combination of LiveKit's useMediaDeviceSelect hook, and an object called UserChoices. Device settings should be accessible from outside a call, but the latter hook should only be used with a room or set of preview tracks, so it couldn't be raised to the app's top level. I also felt that the UserChoices code was hard to follow due to lack of clear ownership of the object.
To bring clarity to media device handling and allow device settings to be shown outside a call, I refactored these things into a single MediaDevicesContext which is instantiated at the top level of the app. Then, I had to manually sync LiveKit's device state with whatever is present in the context. This refactoring ended up fixing a couple other bugs with device handling along the way.
by fixing the cause rather than the symptom: this upgrades the code to use the new, recommended JSX transform mode of React 17+, which no longer requires you to import React manually just to write JSX.
Calls are an environment with high cognitive load, so it's important that we keep extra UI elements like these to a minimum and stick to what's been explicitly designed. I assume that this was here as a developer feature to diagnose reliability of the back end components, which is perfectly fine, so I've kept it behind a developer setting rather than fully removing it.
* respect mute state set in lobby for call
Signed-off-by: Timo K <toger5@hotmail.de>
* move device from lobby to call
Signed-off-by: Timo K <toger5@hotmail.de>
* save device in local storage
Signed-off-by: Timo K <toger5@hotmail.de>
* local storage + fixes
Signed-off-by: Timo K <toger5@hotmail.de>
* device permissions
Signed-off-by: Timo K <toger5@hotmail.de>
---------
Signed-off-by: Timo K <toger5@hotmail.de>
This version is not supposed to properly work, this is a work in
progress.
Main changes:
* Completely removed the PTT logic (for simplicity, it could be
introduced later).
* Abstracted away the work with the media devices.
* Defined confined interfaces of the affected components so that they
only get the data that they need without importing Matris JS SDK or
LiveKit SDK, so that we can exchange their "backend" at any time.
* Started using JS/TS SDK from LiveKit as well as their React SDK to
define the state of the local media devices and local streams.
