The browser history should not be modified from the Connection object,
as this would mess with the history when Talk is embedded in other apps.
Instead it is now modified only from the main Application object when
the main Talk UI is being used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Joining or leaving a call is not an immediate action; in some cases a
few seconds can pass before the action is finished, so during that time
the button should be disabled, both to prevent further actions from the
user and to give her feedback that the action is still going on.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This is a temporal hack, as the proper change would be to move the
modification of elements out of Connection and WebRTC, but for the time
being it will make possible to prevent those objects from modifying
"#app-content" when video calls are added to the details view of Files
app.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "Connection" object should not change the UI directly, so now the
empty content message when the current room is left or deleted it is set
as a response to the "leaveCurrentRoom" and "destroy" events.
As the "deleter" parameter of "leaveCurrentRoom" was only used to show
one message or the other it is no longer needed, so it was removed.
The empty content message set when the room is deleted was also updated
to match the initial empty content message.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The session history is modified by Connection when leaving the current
room for any reason (either because the user explicitly left the room or
because she no longer has access to it), so there is no need to modify
the session history from RoomListView.
For consistency, the session history is now modified only from
Connection when joining a room too, instead of modifying it from both
the RoomListView and Connection.
In any case, modifying the session history should probably done from App
instead as a response to an event, but for the time being this is good
enough.
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 the main UI is used, during a conversation the browser shows the
URL for the conversation, and when the user leaves the room, either
explicitly or implicitly due to a conversation ending, the URL is set to
the main Talk URL.
However, when the embedded UI is used, during the conversation the
browser shows the URL for the public share authentication page, as the
conversation is just an extra element of that page. Thus, when the
conversation ends, the URL should not be modified.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the chat view is shown in the main view the call UI (videos and
screens) is hidden using a CSS trick. However, when there is no chat
view in the main view the elements for videos and screens were always
visible. Those elements are initially "empty", but once the user joins a
call they are filled with contents (like the icon to mute the own audio,
or the avatar of the speaking user). As the elements were always visible
the call UI was shown in the main view after a room was left (either
explicitly or implicitly, for example, if the moderator deleted the
room), as in those cases there is no chat view hidding them.
Besides that, the empty content element was hidden when joining a call
but never shown back again. Due to that when a room was left after
joining a call the empty content element was also missing.
Now the videos, screens and empty content are explicitly shown or hidden
as needed when the user joins a call, leaves a call, or leaves a room,
just like it is done with the chat view.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When we delayed the media access, we were all fast with testing.
Before this patch, when there was already at least one user in the
call and you took longer to accept the media request than webrtc
took to init everything, you would always send a black video signal
and no sound, because the data was not there, when connections were
established with the other users. Now we first request the media and
send the join call to the server afterwards.
Signed-off-by: Joas Schilling <coding@schilljs.com>
Daniel Calviño Sánchez
Joachim Bauch
Ivan Sein
Joas Schilling