Currently the following are implemented:
- AudioMuteButton
- HangupButton
- VideoMuteButton
In order to implement these new buttons a new abstract class was introduced,
which abstracts the ToolboxItem into a button with enough hooks so a stateful
and a stateless version of it can be created.
This patch only adds the stateful implementation of the aforementioned buttons.
This abstraction represents an action which can go anywhere in a toolbox (be
that the main toolbar or the overflow menu) and it's platform independent.
It does not depend on Redux, thus making it stateless, which facilitates its use
in stateful button implementations as well as stateless ones.
Knowledge is power, man!
The config.js cache predates the feature base/known-domains.
Technically, it's also able to recall more domains that the feature
recent-list can (because the latter limits its entries).
Knowledge is power, man!
We moved "knownDomains" from calendar-sync to base/known-domains.
However, we do have an official release in the app stores and I'd like
us to not throw away the knowledge it has acquired.
If multiple JitsiMeetView instances are created (not necessarily
existing at once), it's possible to hit a TypeError when reading the
React Component props of the currently mounted App. Anyway, in certain
places we're already protecting against that out of abundance of caution
so it makes no sense to not protect everywhere.
Make it more generic by accepting any content except of just rows with text and
icons.
In addition, rework its structure so the animation is smoother, by putting the
background overlay outside of the Modal. This way, the animation doesn't affect
the background, which won't slide down.
* fix(toolbar): make button hover bigger
* fix(toolbar): make hangup button bigger
* fix(always-on-top): make toolbar and buttons same sizes as main toolbar
* fix(toolbar): change some tooltips
* fix(toolbar): adjust side panel and filmstrip for new toolbar sizes
It seems that the external API will not send any event to let the sdk
consumer know that the conference has failed if the problem occurs at
the establishing of XMPP connection stage. That's because the config was
loaded successfully, but the conference instance does not exist yet, so
neither base/config nor base/conference will emit any failure.
Make the external API emit CONFERENCE_WILL_JOIN early on SET_ROOM action
which occurs before the XMPP connection is created. At this point we
know that config has loaded and if there's a valid conference room to
be joined. We were thinking of doing that even on CONFIG_WILL_LOAD,
but that seemed to be to risky at this point.
With this the RN component and the consumer app can share same CallKit
provider, configuration, and enable to be part of multiple listeners of
the CallKit flow events. The main driver of this is to enable the
consumer app to be able to report an incoming call to the OS before
loading the JitsiMeetView. Once the user answers the call, the app can
instantiate a JitsiMeetView, pass the CallKit call UUIID, and the Jitsi
Meet components will handle the connection and report back to CallKit
that the call has been established.
Hristo Terezov, Chris Cordle, and I/Lyubomir Marinov agreed that we'd
try to use "invite" & "invitee(s)" in Web/React's iframe API,
mobile/react-native's SDK invite API, and internally for the purposes of
consistency, ease of understanding, etc.
This can happen if there are multiple JitsiMeetView instances are active at the
same time, because there is a single bridge, which means all of them would get
the events.
Currently enterPictureInPicture action can only be dispatched when
the app is on the conference view and the enter PiP button is displayed,
so no check should be necessary.
Activity.enterPictureInPictureMode method must be invoked synchronously
on userLeaveHint callback in order to be sure that the current Activity
is still visible (does not transit to PAUSED state). Previously if the
asynchronous processing would be delayed enough for the Activity to go
into the PAUSED state it will be too late to go into the PiP mode.
To reduce the amount of motion that has to be blurred, use a canvas
to essentially set the FPS of the video background. This canvas
component is behind a temporary feature flag, as well as being able
to disable the blur, so it can be played around with on deployed
environments.
Saúl Ibarra Corretgé
Bettenbuk Zoltan
Lyubo Marinov
Leonard Kim
hristoterezov
paweldomas
Daniel Ornelas
Louis Chen