When an item was selected in the participant menu the menu was closed,
but there was no feedback to the user to let her know that the operation
was still in progress. Now after the menu is closed the button that
toggles it is replaced by a working icon; the button is shown again when
the operation finishes, either shown explicitly if there was an error or
automatically once the view for the participant is rendered again if it
was successful.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For consistency with other menus the participant menu should be closed
when an item is selected; other menus may be implicitly closed when the
request from the server is received and their view is rendered again,
but the participant view "remembers" the menu state, so if it is not
explicitly closed it is automatically opened again when the request is
received.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The participant menu was closed when clicking outside its parent
participant item, but not when clicking on the parent item itself, which
did not match the expected behaviour for a menu. Now it is closed when
clicking anywhere outside the menu or the button that toggles it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a participant is offline the ".participant-offline" CSS class is
added to the element of its view. However, when the view is rendered
again the element itself is reused and only its contents are replaced by
the template. Thus, the CSS class must be explicitly removed from the
element when the view is rendered if the user is now online.
As the CSS class is expected (by the CSS rules) to be set on the
participant element instead of on the link inside it the CSS class was
removed from the template. This makes no difference, though, as
"isOffline" was always undefined and thus the class was never set on the
link.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The endpoints for moderation operations do not fit the default setup for
Backbone models, so the operations are performed directly with AJAX
requests on the view. Thus, after a successful request rendering again
the view has no visible effect, as the model it is based on has not
changed yet. Now the model is updated instead, which will trigger the
render with the new state; that state will be later refreshed with the
server state (although it should be the same) when the model is synced
again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the collection is sorted after an update (for example, if a user is
promoted to a moderator) there is no need to render again each subview
of the participant list; Marionette provides "reorderOnSort" for those
cases, which simply reorders the already existing DOM nodes instead of
rendering the whole list again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Some of the attribute names, as well as the "checkSharingStatus" call,
look like leftovers from a copy-paste; now the proper names are used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The participant list view was rendered on every collection event to
overcome the problem of participant views not being rendered, but that
caused unneeded renderings, for example when the collection was synced
but it had not changed. Now that the id of models in the participant
collection is properly set the view for each participant is rendered
again as expected when the attributes in its model change, so it is no
longer needed to render the participant list on every collection event.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Backbone requires a unique identifier for each model in a collection to
be able to properly sort the models, merge their state when updating
them... In the case of participants the id is their "userId" or their
"sessionId", depending on whether the participant is a user or a guest.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This can be used by third-party apps to get notified about what happens in a
meeting. Also they can use the `BackendNotifier::sendRoomMessage` API to send
custom messages to all users in a room which will then be notified through
the new events.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
Before the file could be opened only when clicking on the name; now it
can be opened when clicking on the preview itself too.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Previews are shown as an image with the file name below it. If the
preview fails to load the "file" icon is shown instead; this is always
the case for guest users, as they have no access to previews.
The parser assumes that rich object messages with a file only contain a
"{{file}}" object and nothing else; the parser then adds a placeholder
element for the preview which will be replaced by the actual preview by
the chat view.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This also converts a "div" element to a "span" element (as it appeared
inside another "span" element, and thus it could not be a block element)
and removes a whitespace between the avatar and the user name (although
it makes no difference, as the whitespaces in the list of items to be
inserted seem to be automatically removed by the "atwho" plugin).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Mentions in the list of messages now show the user avatar instead of an
"@" before the user name. The markup and CSS are based on those used in
the Comments app, although with some small differences (like using the
"mention-user" CSS class) to keep the same visual appearance as before
for "mentions" in system messages (which are not highlighted when they
refer to the current user, and do not show the user name in bold in any
case).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The button, which is shown next to the area to write new messages, shows
a file picker and then shares the chosen file with the room.
Note that currently new files can not be uploaded through the file
picker; only those already in the Nextcloud account of the user can be
chosen.
Also, currently only registered users can share files with a room, so
the button is hidden for guests.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
During screensharing the "participants-X" and "incall" CSS classes were
not updated, which could led to inconsistencies in the UI (for example,
if another participant joined or left the call during screensharing).
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>
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>
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>
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>
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>
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>
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>
Joas Schilling
Daniel Calviño Sánchez
Joachim Bauch