feat(welcome-page): be able to open settings dialog (#3327)
* feat(welcome-page): be able to open settings dialog
- Create a getter for getting a settings tab's props so the device
selection tab can get updated available devices.
- Be able to call a function from a tab after it has mounted. This is
used for device selection to essentially call enumerateDevices on
the welcome page so the device selectors are populated.
- Remove event UIEvents.AUDIO_OUTPUT_DEVICE_CHANGED. Instead directly call
setAudioOutputDeviceId where possible.
- Fix initialization of the audioOutputDeviceId in settings by defaulting
the audio output device to the one set in settings.
* squash: updateAvailableDevices -> getAvailableDevices, add comment for propsUpdateFunction
Refactor welcome page in prep for branding (#3230)
* fix(welcome-page): css tweaks in prep for branded welcome page
- Watermarks should no longer depend on toolbar size. The left watermark made
room for the toolbar when the toolbar was on the left side of the screen, but
the toolbar has been moved to the bottom. The right watermark...well it'll
clash with the vertical filmstrip but at least the margins will be consistent
with the left watermark.
- Apply new font-family so fonts are more likely to be consistent across the
app. Design likes SF UI and keeps requesting it so use it by default.
- Change sizings of welcome page header to be more responsive. This will help
the header be scrollable when there is no additional content and the header
overflows.
- Change colors of the welcome page header and remove background image that
was in the header. Leave in the dom for the background image in case other
deployments need to continue showing an image.
- Add a period to the title of the welcome page.
- Move watermarks dom location as it is not part of the header; it's part of the
whole page.
* [squash] Size and font adjustments. Renaming.
[RN] Don't request camera permission on first launch
It will only be requested if a user joins a meeting or flips the switch from
video to audio and back, but never as the first thing when the welcome page is
mounted.
feat(App): refactor App and split it into BaseApp and App
BaseApp does all the heavy-lifting related to creating the redux store,
navigation, and so on.
App currently handles URL props and actually triggering navigation based on
them.
Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.
This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.
In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:
- JitsiMeetJS initialization is now synchronous: there is nothing async about
it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
support can now be detected immediately, so take advantage of this to simplify
how we handle unsupported browsers. See [0].
The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.
[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779
Reduce direct read access to the features/base/participants redux state
As part of the work on fixing the problem with the multiplying
thumbnails, we've associated remote participant w/ JitsiConference.
However, there are periods of time when multiple JitsiConferences are in
the redux state (and that period is going to be shorted by
StateListenerRegistry). In order to give more control to the feature
base/participants, reduce the occurrences of direct access to the
features/base/participants redux state and utilize the feature's
existing read access functions. Which will allow us in the future to
enhance these functions to access participants which are relevant to the
current conference of interest to the user only.
[Android] Fix possible TypeError in multi-JitsiMeetView SDK consumers
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.
In order to be able to add analytics to the deep-linking pages the
lib-jitsi-meet initialization has been moved so it happens earlier.
The introduced `initPromise` will eventually disappear, once conference is
migrated into React and / or support for Temasys is dropped. At that stage, it
can be turned into a sync function which all platforms share.
* feat(Deeplinking): Implement for web.
* ref(unsupported_browser): Move the mobile version to deeplinking feature
* feat(deeplinking_mobile): Redesign.
* fix(deeplinking): Use interface.NATIVE_APP_NAME.
* feat(dial_in_summary): Add the PIN to the number link.
* fix(deep_linking): Handle use case when there isn't deep linking image.
* fix(deep_linking): css
* fix(deep_linking): deeplink -> "deep linking"
* fix(deeplinking_css): Remove position: fixed
* docs(deeplinking): Add comment for the openWebApp action.
Improve the experience when joining a room by removing the need to tap the join
button. The keyboard type has also been set to "go", which translated on the
builtin keyboard button label to be "go" (it's builtin, the operating system
translates it). This works on both Android and iOS.
yanas
Ritwik Heda
virtuacoplenny
hristoterezov
Saúl Ibarra Corretgé
Lyubo Marinov
Bettenbuk Zoltan
Guus der Kinderen