Although more a helper class than a model, this will make possible to
join and leave the room for a file from different views.
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>
In Nextcloud 15 the default Content Security Policy disallows unsafe
eval expressions, so Handlebars templates can no longer be compiled at
runtime.
For the time being that default Content Security Policy was lifted for
Talk so "Handlebars.compile" could still be used. However, this only
applies to Talk itself; when using Talk components in other apps they
must abide to the Content Security Policy of those apps. As
MediaControlsView is going to be used in the Files app it has been moved
to precompiled Handlebars templates (which are still compatible with the
regular Talk UI).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When "startWithoutLocalMedia" is called there is never audio nor video
(otherwise "startLocalMedia" would have been called instead), so there
is no need to call "isAudioEnabled" nor "isVideoEnabled". Moreover,
"initAudioVideoSettings" performs the same setup as the custom handling
in "startWithoutLocalMedia", so that custom handling can be replaced by
a call to "initAudioVideoSettings".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The items in "app-navigation-entry-menu" lists were forced to be
displayed as blocks with an "!important" rule, so inline rules were used
to hide some items in the screensharing menu.
However, forcing the items in "app-navigation-entry-menus" lists to be
displayed as blocks is no longer needed; that class is only used in the
room list menus and in the screensharing menu, and both work fine
without it. Moreover, the server provides rules to hide items in those
menus by adding the "hidden" class, so that approach is used now instead
of the inline styles.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the video is set as available there is no need to show the video
UI; it will be shown as needed when calling "enableVideo".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
SimpleWebRTC emits the "localstream" event after a successful call to
"start/startLocalMedia". In turn, this is only called from
"startLocalVideo", which emits "localMediaStarted" if "startLocalMedia"
succeeded; "localMediaStarted" is handled by calling "startLocalMedia"
in the app, so now the setup done when handling "localstream" is merged
with the setup done when handling "localMediaStarted".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In a similar way to the video button, now the audio button does not
handle the click event if audio is not available, instead of treating it
as disabled and trying to enable it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"videoWasEnabledAtLeastOnce" was used to allow or prevent the handling
of clicks on the video button. However, it was enabled in the handler
for the "localstreams" event, so it was being enabled even if there was
no video (although it was disabled as needed later during the handling
of the "localMediaStarted" event). In any case, its purpose can be
covered by "videoNotFound", so it was removed in favour of the last.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The empty content message shown when waiting for others to join the call
depends on the state of the room. Thus, now the message is updated if
there are changes in that state, like the participants or the type of
the room.
The updates need to be disabled when WebRTC is not supported and when
waiting for the media permissions to prevent those messages from being
overriden; the updates are enabled again once the media permissions were
granted, or if they were rejected but it is possible to join the call
nevertheless (that is, if WebRTC is supported).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The main empty content message is kept in the templates generated by the
server to be able to show something to the user while the rest of the UI
is loading.
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>
Rooms are now deleted by using the standard "destroy" method of Backbone
models instead of calling the endpoint directly from the view. In a
similar way, the current user now removes herself from the room also by
destroying the model, but with a special URL. This will make possible to
listen to and handle the "destroy" event of the model from other places.
Leaving the current room when it is destroyed or removed was also moved
to the model; for consistency, the model now provides a method to join
the room too (which, in the end, will also synchronize the model).
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>
Restoring the message once the permissions were granted or not could
lead to the wrong message being shown if a different message was set in
the meantime; this would typically not happen in the general UI, but it
was a problem that had to be worked around in the "Request password" UI
by not using the main "syncAndSetActiveRoom" method.
As the message to be restored is deterministic now it is explicitly set
instead; it will always be the "Waiting for others to join the call"
message, except when WebRTC is not supported which will not be modified.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before, the empty content message informing the user that WebRTC was not
supported was set only when WebRTC was initialized. Due to this the
message could be overwritten when changing to a different room, and when
starting/joining a call in that other room the "Waiting for others"
message was shown instead. Now the "WebRTC is not supported" messages is
set on every call to prevent that.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The additional message with the URL of the room is now shown also for
guests; the icon shown to guests is also fixed (now the link icon is
shown instead of the contacts icon, which is the one used for group
rooms).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before, the message explicitly mentioned the other user and her avatar
was used as the icon only for one to one rooms. Now that will be done
for any type of room if there is only another registered user and no
guests in that room.
In a similar way, the additional message hinting how to invite other
users now is always shown in group and public rooms, no matter how many
users are currently in the room; this is the same as before for public
rooms, although it was changed for consistency for group rooms, as in
that case the message was shown only when there were no other
participants in the room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This also fixes the additional message in group rooms, as it was shown
only for the owner, but not for moderators due to a wrong
"participantType" value.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now "Waiting for {participantName} to join the call" will be shown only
if there is no other guest besides the current one in the room;
otherwise it would be unexpected that the call started when another
guest but not the mentioned participant joined it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The room message should be updated as a response to a change of the
active room, and not when the room list view is rendered.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the details view is opened for a file the "shareTypes" of the
FileInfo are initially strings; they are converted to integers only once
the "Sharing" tab has been opened. Thus, now the "shareTypes" are always
"casted" to integers before performing a strict comparison against the
"SHARE_TYPE_XXX" constants.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note, however, that the participant will never receive that message from
the signaling endpoint, but a 404 error due to the room no longer
existing. In any case, this ends the pending signaling request as soon
as the room is deleted instead of keep waiting until the timeout ends.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a participant is removed or disconnected from a room the
"refresh-participant-list" signaling message is added to all the
participants in that room. However, the participant just removed or
disconnected is no longer in the room, so the message needs to be
explicitly added for that participant.
Note, however, that the participant will never receive that message from
the signaling endpoint, but a 404 error due to no longer being in the
room. In any case, this ends the pending signaling request as soon as
the participant is removed or disconnected instead of keep waiting until
the timeout ends.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This commit introduces a DetailTabView plugin to show a chat view in the
sidebar of the Files app. The tab makes possible to chat in a Talk room
associated to the current file; due to this, the tab is visible only on
files that can be associated to a room, that is, files shared with the
current user or by the current user to another user (as a user, group,
circle...).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Daniel Calviño Sánchez
Joas Schilling
Nextcloud bot
Joas Schilling
Ivan Sein