ref(toolbar): show recording features based on explicit configs (#3080)
* ref(toolbar): show recording features based on explicit configs
* squash: bring back button configs, use final config names
* squash: update interfaceConfig comment, remove unused config whitelist
* squash: change order of button enabled checks to reduce diff
* squash: fileRecording -> fileRecordings
feat(recording): add sounds for when recording starts and stops (#3078)
* feat(recording): add sounds for when recording starts and stops
* squash: use constants, play sounds for file only
* squash: rename recordingStopped.mp3 -> recordingOff.mp3
* squash: flip var declaration for alpha order
Layout:
Use an absolute-fill view as the background with the sidebar on top of. This
greatly simplifies styling, as there is no need to calculate how large the
backdrop needs to be.
Animation:
Switch to a translateX transform animation. This serves 2 purposes: first,
there seems to be a bug somewhere in React Native 0.51-0.55 where the content
that is being animated starts to be clipped. Very weird! But more importantly,
translateX transmorm animations are supported by the native animation driver!
https://facebook.github.io/react-native/blog/2017/02/14/using-native-driver-for-animated.html8f5ebe5952/Libraries/Animated/src/NativeAnimatedHelper.js (L138-L176)
This makes the animation more performant and buttery smooth.
Some small cleanups are also included here.
ref(video-layout): get dominant speaker state from redux
Instead of keeping dominant speaker locally, get it from redux and be
updated when the dominant speaker changes. This is in an attempt to mimic
the video layout being reactified and connected to redux.
The visibility of the toolbar can be toggled by interacting with the main screen.
This change allows the toolbar to be configured to be 'always visible'. This voids
the 'toggle' functionality.
Simplify parts of the logic introduced in
11b7144ad0.
Specificaly, using all the state change avoiding functions doesn't give us much
since we need to copy the state for sure.
fix(base/participants): ensure default local id outside of conference
Makes sure that whenever a conference is left or switched, the local
participant's id will be equal to the default value.
The problem fixed by this commit is a situation where the local
participant may end up sharing the same ID with it's "ghost" when
rejoining a disconnected conference. The most important and easiest to
hit case is when the conference is left after the CONFERENCE_FAILED
event.
Another rare and harder to encounter in the real world issue is
where CONFERENCE_LEFT may come with the delay due to it's asynchronous
nature. The step by step scenario is as follows: trying to leave a
conference, but the network is not doing well, so it takes time,
requests are timing out. After getting back to the welcome page the
the CONFERENCE_LEFT has not arrived yet. The same conference is joined
again and the load config may timeout, but it will be read from the
cache. Now the network gets better and conference is joining which
results in our ghost participant added to the redux state. At this point
there's the root issue: two participants with the same id, because the
local one was neither cleared nor set to the new one yet
(PARTICIPANT_JOINED come, before CONFERENCE_JOINED where we adjust the
id). Then comes CONFERENCE_JOINED and we try to update our local id.
We're updating the ID of both ghost and local participant. It could be
also that the delayed CONFERENCE_LEFT comes for the old conference, but
it's too late and it would update the id for both participants.
The approach here reasons that the ID of the local participant
may be reset as soon as the local participant and, respectively, her ID
is no longer involved in a recoverable JitsiConference of interest to
the user and, consequently, the app.
Co-authored-by: Pawel Domas <pawel.domas@jitsi.org>
Co-authored-by: Lyubo Marinov <lmarinov@atlassian.com>
If the ID of a remote participant was the same as the ID of the local
participant (across multiple conferences), removing the remote
participant on PARTICIPANT_LEFT would remove the local participant.
Like the preceding commit "ref(base/conference): clear the 'conference'
field on WILL_LEAVE", this commit is part of the story how we are to
deal with conferences which take noticeable time to leave.
Like the preceding commit "ref(base/conference): clear the 'conference'
field on WILL_LEAVE", this commit is part of the story how we are to
deal with conferences which take noticeable time to leave.
If a leave is delayed and the leaving JitsiConference manages to sneak a
PARTICIPANT_JOINED in, it may create a remote participant who even
collides with the local participant.
With so many abstractions called conference, I'm not surprised I made a
mistake and my reviewer didn't catch it.
As we are transitioning from remote participants identified by ID alone
to an ID-conference pair, the subsequent commits "Protect against late
PARTICIPANT_JOINED" and "Refine PARTICIPANT_LEFT for ID collisions"
caught the error.
ref(base/conference): clear the 'conference' field on WILL_LEAVE
Pawel Domas said:
The conference state field is referring to the current conference in
progress, so it feels like this field should be cleared as soon as we
declare that the conference is being left and the asynchronous process
of leaving the conference starts (which happens on
CONFERENCE_WILL_LEAVE).
Lyubo Marinov said:
Merely setting conference to undefined is incomplete because there are
other redux state properties associated with conference.
What we're doing here is redefining the redux action
CONFERENCE_WILL_LEAVE:
The redux action CONFERENCE_WILL_LEAVE represents the order of the user
to leave a JitsiConference instance. From the user's perspective, there's
no going back (with respect to the instance itself). The app will perform
due clean-up like leaving the associated room, but the instance is no
longer the focus of the attention of the user and, consequently, the app.
Now CONFERENCE_LEFT and CONFERENCE_WILL_LEAVE have more in common than
before and we can do a much better job by expressing the common parts in
source code. Additionally, our source code can be rewritten to better
express the meaning of any of these two actions.
Co-authored-by: Pawel Domas <pawel.domas@jitsi.org>
Co-authored-by: Lyubo Marinov <lmarinov@atlassian.com>
Add ability to provide a display name in the configOverwrite object that
when available it will be used to customize the name of the meeting in
callkit screen and recent call list.
Co-authored-by: Daniel Ornelas <daniel.ob64@gmail.com>
Co-authored-by: Lyubo Marinov <lmarinov@atlassian.com>
This zOrder change fixes the issue that the scrollable filmstrip videos
rendered in front of the local participant, however there is still an
issue that needs to be fixed later: The rendered videos should have
overflow: 'hidden' property applied so then they don't get rendered when
scrolled out of the ScrollView, that property however doesn't seem to
work for Video components.
This fix is based on storing the location URL object we are loading the
configuration for in the redux store. Once the config has been loaded (or it has
failed, for that matter!) we'll check if the current "config URL" is the same we
set, and discard the old one if they don't match.
Guus der Kinderen
virtuacoplenny
paweldomas
Lyubo Marinov
Saúl Ibarra Corretgé
Bettenbuk Zoltan
hristoterezov
Daniel Ornelas