Removed annoying overlay that blocked the user. (feedback from @spaccoud)
Previous design required one click too many. As this dialog doesn't need
an overlay, I couldn't use the default primitive.
It's a hacky but functional, creating technical debt here.
Closer to the Gmeet design. Added a warning about permissions
since the rooms are public in beta.
Apologies @manuhabitela, this may impact accessibility for users unfamiliar
with the copy icon. Let's conduct user testing.
Messy code file organization, but functions are okay. Functional, but not
well-designed and likely hard to maintain. Shipping it, creating technical
debt here. Will be reused for interactions with LiveKit server API.
Participants need to be room admin to interact with LiveKit server
api. Until we offer private room, with moderation, all participants
will be considered as room admin.
note: room admin doesn't offer permission to record a room. please,
refer to LiveKit documentation to learn more.
This commit focuses on the UX more than the code quality. In facts,
we should design a centralized component/alert service, that we
can trigger anywhere in the codebase, when a user is prompted for
confirmation.
The alert modal with cancel/submit buttons and a description is generic.
Creating technical debt here.
Rapidly, a 'more option' button should be added to the row. Thus,
participants will have access to few more actions (ex: remove from
the room, pin camera, etc…).
This flex layout should be definitive, except the code which is dirty,
but not creating much technical debt here.
First raw iteration.
Tried replicating Gmeet UX and layout. However, in their ux, even if
action button are disabled, some tooltips explain to the user why they
cannot perform the action. With the default Trigger, it's not easily
feasible. As soon as the button is disabled, there is no way to trigger
the tooltip in an uncontrolled manner.
In upcoming commits I'll arrange layout, and call the remote LiveKit
ServerApi, to perform the mute action.
Main update: create a component, which has the responsability of
rendering a Participant in the list. I tried gettig closer to a
cleaner codebase, with small and well-scoped components. WIP.
Formatting participants before rendering the list was way to over
complicated, iterating twice on the list was kinda useless. Fixed!
Few updates:
- Removed capitalizing Participant's name to be consistent with the
avatar. This choices mimics GMeet UX.
- Duplicated isLocal utils function from LiveKit, which is not
exported by their package.
Avatar font size was way too small in the participant list context.
I tried improve it. Few font sizing are visually uncomfortable in
the participant list.
oupsy, heavily copied from Gmeet.
Thx Nathan Vasse for his css animation skills, he crushed it.
This component will be core in the app, and reused in many places.
It was necessary for the participants list.
Upgrading Django to 5.1 created a severe issue.
Migrate and create-superuser jobs were failing.
The issue originated from the third party easy_thumbnail.
Please refer to the issue #641 on their repo.
This is the suggested workaround by @Miketsukami.
It explains why participant initials doesn't update when a participant
changes its name.
Similar issue as the one faced while developing on the participant list.
It needs to be fixed at the root, in the LiveKit repo.
Duplicated source from LiveKit internal hooks (not ideal, but necessary)
to ensure the inner content of the participant placeholder consistently
fits its parent container. Unfortunately, I couldn't find
a simpler solution.
This might lead to some performances issues, as for each tile, some js
would be computing avatar's size, which is much more costly than pure
css…
Note: Gmeet achieves this by generating a temporary placeholder image
with a colored background and initials, allowing for a perfectly round,
responsive avatar without relying on JavaScript.
Default 'transparent' value avoid showing the avatar when
participant's info are not yet available. Might be a bad design
if we follow the single responsability pattern. Please feel free
to refactor it.
Color is stored in participant's metadata.
Using a hash of some participant's info allow to persist the color
for logged-in participant without storing the color in db.
Please feel free to tune the saturation and lightness range.
Code is inspired by a tutorial found online.
Inspired by Gmeet animation (mine is far from perfect).
Some details should be improved, especially to have a smooth
animation stop when the user stops speaking.
Duplicated LiveKit sources to customize the participant tile. It’s needed
to enhance the design and color of the participant placeholder.
More in the next commits.
Inspired by the Google Meet user experience.
A simple UX for scheduling meetings was requested by some users.
This is a quick and basic poc to validate the UX in a production
environment. If it gains traction, it will be refined and consolidated.
Inspired by GMeet user experience. Offer a sound tester button
to our users while configuring their audio output.
uprise.mp3 has a free license. We should credit them in our legal
terms asap.
First draft, it lacks important features, as a visual indicator when
the mic is active, and a trigger to test the audio output.
I made some heuristics (e.g. default output/input, etc..) to ship a
first version of this setting tabs that should work good enough to
create value for our current users.
Please refer to the inline comments.
Introduced a General settings tab, currently allowing language configuration.
Although this commit introduces some duplication, the default settings dialog
will be refactored in future updates.
The General tab is designed to accommodate additional features over time.
User can now update their name in a dedicated Account tab,
inspired by Jitsi design. Removed the username dialog.
Account-related updates will be operated through the advanced
settings dialog, in this dedicated tab.
Inspired by other videoconferencing tools' designs.
Sizes are mixing pixels and rem, it should be harmonized.
Will be used by the advanced settings panels.
Refactored it in a proper component. Initially planned to
use it in the Account Tab, but I changed my mind.
This refactoring is an enhancement, the Avatar props are better
encapsulated.
This component should be the definitive layout for settings.
Why extended? I kept the original one, which is still in-use in the
homepage, and considered this settings dialos as an extended version,
or advanced one.
I hope in a close future, we merge these two dialogs to avoid
maintaining too much code. Not the top prio.
Relevant TabPanel components will be introduced in the upcomming commits.
Even if the list is empty, previous assertion was returning true.
Fixed it, mybad, noob error.
In fact, the participants list should never be empty, as you are
in the meeting to access it.
The 'Box' component has a type 'dialog' which limits the Dialog size.
The default size is insufficient for larger dialogs like
the advanced settings.
To address this temporarily, I'm allowing the wrapper component to set the
Dialog size directly. This isn't ideal, but will enable better flexibility
until we finalize the user experience and dialog requirements.
I am not sure of the new props' naming introduced.
Added a new variant for Tabs and TabList components
to support borderless styles.
By default, both Tabs and TabList include borders.
Using React context, TabList’s children will automatically
inherit a borderless style if specified via props.
However, you can still explicitly apply borders
to individual children, even if the parent
TabList is set to be borderless.
Style react aria components and exposed them.
Tabs are needed for the advanced settings component.
Both orientations, horizontal and vertical, are supported.
Introduce an option to render or omit the title in the Dialog component.
This is necessary for the advanced settings Dialog, which displays its
title in the Tab menu.
This could affect existing component API created by @manuhabitela.
The component will become less opinionated, offering more flexibility
in its usage (I am not 100% convinced it's actually a great idea).
Quick fix! Let's enhance it
Text.tsx export not only a component, but also few types.
This triggers an eslint warning. I don't want refactoring it
without discussing it with @manuhabitela. Silence it.
@manuhabitela introduced Menu and MenuTrigger components. Refactor the
options menu to benefits from his components.
Few details are not perfect yet. wip
it seems panda-css didn't like my way of sharing css code. When sharing
bare objects matching panda-css interface, panda-css didn't understand
those were styles and didn't parse them. Now using actual recipes via
the `cva` helper, panda understands correctly those styles need to be
updated on change.
ps: cleaned a few panda imports that didn't use our "@" alias
this will be used for toggled on/off mic and camera buttons. We want
toggled-on buttons that don't look pressed as it looks a bit weird
(we'll change icons on pressed/unpressed state). And we want red buttons
for when the buttons are not pressed, so adding the "danger" variant
too.
the whole colorpalette stuff needs a bit of work to be clean but it'll
do for now
