Add support for video calls when requesting the password for a share #1123

This reverts commit 112c73b.

Every time that a conversation to request a password was successfully created a new handler for the signaling event was registered. Thus, if a password was requested, the conversation ended, and the password was requested again from the same page then each event had two handlers. Until now, due to the behaviour of the handlers, even if incorrect it was not a problem. However, in preparation for changes to the "joinRoom" handler now a single handler is registered for each signaling event, no matter how many passwords were requested. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

The implementation of "connection.joinRoom" calls "app.syncAndSetActiveRoom", which performs several actions needed when the full Talk UI is used, but unneeded when the embedded Talk sidebar is used. Moreover, as it is not possible to know when the rooms were synced, joining the call after joining the room could lead to UI issues due to the order in which elements were setup (for example, the empty content message "waiting for permissions" could be shown instead of "waiting for XXX to join the call"), so this is also a needed change to be able to add support for video calls. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

This is needed to show notifications using the standard "OC.Notification.show" function, which is used by some Talk functions. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

When a password is requested now the guest automatically joins the call, and once the sharer joins the call too a video call view appears in the Talk sidebar. Although it is not currently shown, the empty content message for guest users was set, as it is expected to be set by some event handlers. In a similar way the "#screens" element was also added, but there is no support yet for screensharing and thus the element is kept always hidden. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

When a screen is shared it takes the upper area of the call container, and the videos are shown below it in a 200px high row, just like in the normal Talk UI. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

The local video (or avatar) and the media controls to mute own audio, disable own video or share own screen are now included in the main view of the sidebar, just like in the normal Talk UI. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

The empty content message informs the user when the app is waiting for the media permissions and then when it is waiting for the sharer to join the call. Thus it is now shown above the chat view, in the place that will be occupied by the call container once the call starts. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

In the public page for a conversation the token is always defined, so the signaling can be initialized as soon as the app starts. However, in the public share auth page the token is only available once the password is requested and the room created, so trying to initialize the signaling when the app starts ends in failed requests to the room endpoint. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

Signed-off-by: Joas Schilling <coding@schilljs.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for video calls when requesting the password for a share #1123

Add support for video calls when requesting the password for a share #1123

Commits on Aug 8, 2018