Until now only the opacity of the avatar was reduced when the peer was
not connected. However, if the video was being shown the avatar was
hidden, so if there was an issue with the connection to the other peer
it was not reflected in the VideoView.
Note that the loading icon should be shown too in the video for long
disconnections or failures, but ":after" CSS pseudo classes (which are
used by the loading icon) do not work with video elements, so for now
only the opacity is reduced.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Until now the opacity of the avatar was reduced when the peer was
created until it got connected for the first time. Now the opacity of
the avatar is reduced whenever the peer is not connected. In practice,
the difference is that now the opacity is changed too when there are
issues with the connection to the other peer.
Note that the issues were already signaled using the loading icon, but
only after a long disconnection; now the opacity is reduced as soon as
there is a disconnection, which provides quicker feedback of the issue
while keeping the previous behaviour (as the loading icon is still shown
in a long disconnection).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The chat messages are expected to have the full width of its content
row, except for some space used for the date. However, as chat messages
are left padded that padding must be included too in the width;
otherwise there could be no room for the date.
This is only a problem in the public share authentication page, as apps
use by default "box-sizing: border-box" in all its elements.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Rename buttons for guest participants and rooms should always be visible
(at least with opacity) to make their very existence more obvious.
Before they were always hidden and shown with full opacity when the
cursor was on the label wrapper, even if it was possible to interact
with the button only when the cursor was on it. Now, as the buttons are
always visible with a low opacity, the full opacity is set only when the
cursor is on the button itself and thus when it can be interacted with.
Signed-off-by: Sascha Wiswedel <sascha.wiswedel@nextcloud.com>
The server explicitly sets the height of confirm icons inside password
inputs, which overrides the height set in Talk for submit inputs in the
authenticate page. Therefore, the height set by the server needs to be
overriden to honour the height set in Talk (which matches the height of
the password input in the authenticate page).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Due to how Internet Explorer 11 sorts CSS rules based on their selector
and how the "#app-content" left margin is set in the server it is
necessary to set the ":fullscreen" rule as important to override the one
from the server, which is sorted above it (unlike in the rest of
browsers).
Besides that, the top space added to the sidebar when IE is used needs
to be removed in fullscreen mode, as in that case there is no header.
The sidebar height also needs to be explicitly set to 100% due to the
lack of support for "unset" in Internet Explorer 11.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The sidebar top position in Talk is set to 0. However, the server sets
the position of the sidebar as fixed when IE is used, so in that case it
needs to be pulled down to not overlap with the header.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In Nextcloud 16 the default height for input elements, as well as the
confirm icons inside them, is 34px. This caused the room name input to
change its height from 44px to 42px, so it is no longer needed to pull
it up 2px to prevent moving the items below when it is shown. In a
similar way, it also caused the confirm icon to change its height from
42px to 34px; it was misplaced down 1px, so now it is positioned 4px
from the top (instead of 5px to keep the same position as before).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "Add" button is shown only for logged in users, so it is not shown
in guest pages. However, when the chat view is shown in the sidebar in a
guest page there was an empty space where the "Add" button would have
been shown for a logged in user. Now the message input stretchs to use
that empty space.
Note that this is only applied when the chat view is in the sidebar;
when the chat view is in the main view the "Add" button is added in the
padding area used to frame the chat view, so in that case the empty
space should be kept.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the current participant is a logged in user the "Add" button is
shown in the chat view, and due to some arcane CSS magic that button
caused the chat view to be moved to the left (instead of simply
appearing to the right of the message input, wherever that be). The same
arcane CSS magic causes everything to look fine when using the same
approach as in the sidebar of the regular Talk UI, that is, applying a
"margin-right" to the form to make room for the "Add" button, so that
margin is now applied in the public share auth page when needed (that
is, when the user is logged in).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"guest.css" overrides the default style of links set in "style.scss"
(core), which causes links in the public share auth page to be white and
with a stronger weight. Due to this, the rules from "style.scss" need to
be restored for links in the Talk sidebar to get the proper appearance.
Note that, unlike in other restored rules, in this case it is not enough
to use "#talk-sidebar" as the main selector; "#body-login #talk-sidebar"
needs to be used in this case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The pointer cursor should be used on clickable elements, but clicking on
a selected tab header has no effect, so now the default cursor is used
instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Icons paired with the "force-icon-white-in-call" CSS class need to be
explicitly coloured in white; otherwise they are shown with the default
black colour.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For consistency with the video element, other elements in VideoView are
now hidden and shown using the "hidden" CSS class.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For legacy reasons the "incall" CSS class, which is used to hide and
show the empty content view and the call container as needed, and the
"screensharing" CSS class, which is used to adjust the call UI when
there are shared screens, were set in the "#talk-sidebar" element of
PublicShareAuth. For consistency with the embedded Talk UI now the
classes are set in the "#call-container" instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"guest.css" overrides the default style of inputs set in "input.scss",
which causes all inputs in the public share auth page to look like the
main password input. Due to this, the rules from "input.scss" need to be
restored for inputs in the Talk sidebar to get the proper appearance.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"guest.css" sets ".button" elements to inline-block display, but the
edit button, which is a "span", is expected to be displayed as inline to
get the proper size.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the editable text label for room names was fixed the rules were
added for all editable text labels, which broke the editable text label
for guest names. Those rules are now applied only to room names, which
implicitly fixes guest names.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When ".icon-white" was replaced by ".force-icon-white-in-call" the
server rule that sets shadows to ".icon-white.icon-shadow" elements no
longer applied to icons in calls. Due to this it is necessary to
explicitly set the shadows for ".force-icon-white-in-call.icon-shadow"
elements to ensure that they are visible on bright video backgrounds.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "incall" CSS class is currently set in "#app-content",
"#talk-sidebar" and "#call-container", depending on whether the call
happens in the main Talk UI, in the public share authentication page or
in the Files app.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
While a message is being sent the submit button in the chat view is
hidden by setting the "hidden" CSS class to it. However, in "guest.css"
an explicit "display" property is set for submit buttons; this rule is
more specific than the generic rule for ".hidden" elements, and thus
overrides it, causing the submit button to be shown even when the
"hidden" CSS class is set. Therefore, an explicit rule is needed to set
"display: none" for hidden submit buttons.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The submit button in the chat view is positioned using its "bottom"
property to align it with the bottom of the new message form even when
there are several lines and the form grows vertically.
"publicshareauth.css" (core) sets the "top" property of submit buttons,
which causes the submit button in the chat view to be aligned to the top
of the new message form, and thus needs to be overriden.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
After moving the room name into a flex container the room name input no
longer expanded to fill the whole width of the sidebar.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The rules for the opacity of the submit button for the chat message
input were not merged with the generalized ones due to "styles.scss" not
being included everywhere that "chatview.scss" is included (for example,
in the Talk sidebar for the Files app).
The rule explicitly excludes a hovered or focused submit button, as due
to specifity in this specific case the rule for the focused input
overrides the rule for hovered or focused submit buttons (even if in the
generalized ones it is not necessary to explicitly exclude those
states).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The authentication page uses pure CSS instead of the SCSS styles, so the
rules were adjusted as needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In the server the pointer cursor is set for the whole menu item. In the
pop up to set the room password only the button in the password field is
clickable, so the pointer cursor should not be used for the whole menu
item.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The button is highlighted to convey that it can be interacted with, so
it should not be done if the button is disabled.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The guest name now behaves like the room name regarding the opacity of
its submit button.
Both the room name and the guest name are editable text labels, so the
CSS rules were moved from the room name to the editable text label.
However, although the guest name uses the default server rules for the
input and the submit button the room name does not (they are adjusted to
better fit a header); the rules set for the editable text label are
based on the default server rules, and the room name inherits the rules
for the editable text label customizing them as needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As ".room-name" and ".guest-name" elements are also
".editable-text-label" elements the rules for the later, which should be
more generic, are moved above the rules for the specific elements.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the input field for the room name is focused pressing enter sets
the room name without having to explicitly click on the submit button.
To hint this behaviour now the opacity of the submit button is slightly
increased when its input field is focused.
Due to the specifity of the CSS rules, the one for the focused input
needs to be defined before the other to get the full opacity of the
button when it is hovered and the input is also focused.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For consistency with the button to send a new chat message the submit
button is now by default at a opacity of .3 and is shown in full opacity
only when hovered/focused/active.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the "Chat" tab is selected for a different file a new room is
loaded. However, as first it has to be checked if the Talk sidebar is
supported for the file, which may require a query to the server, and
then the messages for the new room need to be fetched some time can pass
between selecting the tab and rendering the messages for the new room.
Due to this now a "UI not ready" placeholder is shown in the "Chat" tab
while a new room is being loaded, which prevents the messages of the old
room from being shown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In Nextcloud 15 icons were added to the tab headers in the sidebar; due
to the shared CSS rules this broke the position of icons in the tab
headers of Talk.
For consistency with the server, the tab header icons were not fixed to
their previous position (to the left of the label), but to the same
position used in the sidebar of the server (above the label).
To do this the icon was simply extracted from the link to use the same
markup as the server.
However, there are still some differences between the tab headers in
Talk and in the server; in Talk the whole tab header is highlighted when
hovered, so now that the icon is in a separate element it should use the
same opacity rules, specific to Talk, as its link.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In the server, ".icon-file" is set to the "text" icon instead of to the
"file" icon. For consistency with the server and between the room list
(which uses ".icon-file-white") and the icon to go to the file (which
uses ".icon-file") now ".icon-file-white" uses the "text" icon too.
Note, however, that the icon for shared files that do not have a preview
is still the "file" icon, as in that case it should reflect the file
contents and using a text icon for other types of files could be
misleading.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If a room is associated to a file now an icon is shown to the right of
the room name; when that icon is clicked the Files app is opened in a
new tab and focused on the file.
The "Go to the file" hint is shown using the tooltip plugin instead of
the link title for consistency with other buttons in the UI, and because
it is automatically shown when the icon is focused while traversing the
UI elements with the tab key.
The icon has a clickable area of 44x44px; due to how the properties for
h2 elements are defined in the server some margin juggling is needed to
vertically align the icon with the room name header.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
To provide a stronger feedback that the action is still going on now a
working/loading icon is shown in the call button while joining or
leaving a call.
In the Files app the call button width depends on its text (in the
regular Talk UI it depends on the sidebar width), so the padding was
increased to always make room for the icon, even when hidden, to prevent
a sudden increase of the width when the icon is shown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Swapping the "public-room" and "private-room" CSS classes comes from the
time in which the share link was shown in the room list. However, since
the share link was moved to the sidebar the "public-room" and
"private-room" CSS classes are not set anywhere, so their switching code
as well as their CSS rules can be removed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before, the "Chat" tab was shown only when the file was shared. This
made the feature hard to discover if you did not know about it.
Moreover, after sharing the file the details view had to be closed and
opened again, which was cumbersome, as there were no events to listen to
and the visibility of tabs can not be updated once shown either (at
least, without some hacks).
Due to all this now the "Chat" tab is always shown for files (although
not for folders); if the file is already shared the previous UI (call
button and chat view) is shown, and if it is not a message to inform the
user that the file needs to be shared is shown instead. This is updated
every time the tab is opened again, so after sharing the file going back
to the "Chat" tab will show the call button and the chat view.
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>
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>
The CSS rules specific to the autocomplete list for mentions in the chat
view were applied to any other autocomplete list. In the main Talk UI
this is not a problem, as that is the only autocomplete list, but it
could be when using the Talk chat view in other components, like the
Files app.
The autocomplete list is created as a child of the body element itself,
so to limit the CSS rules only to the chat view it is not possible to
just prepend "#chatView" to the rules. Instead, now each item has a CSS
class (hopefully :-) ) unique to the chat view.
Unfortunately, it does not seem to be possible to ensure that the rules
defined in "autocomplete.scss" will not collide/override rules defined
in other apps, as customizing the CSS classes in ".atwho-view" so the
rules are applied only when it belongs to the chat view does not seem to
be possible (except, maybe, with some hacks).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"CommentsTabView" is a legacy name from the original import of the code
from the Comments app; besides being a better fit, "ChatView" also
ensures that the CSS rules will not conflict with those from the
Comments app when the Talk UI is used in the Files app.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"guest.scss" in server sets the "width" and "margin-top" properties of
".wrapper" elements to position the main content of the public share
authentication page. However, as the selector used in the rule is too
broad it is also applied to the internal wrapper of the virtual list, so
the properties need to be reset in that case.
Besides that, the padding of the message list is ignored when using the
virtual list, so that padding needs to be applied through the "left" and
"right" properties of the internal wrapper of the virtual list.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The virtual list requires that its internal wrappers use an absolute
position. Due to that absolute position the padding of the container
does not affect the wrappers, so the desired padding must be applied
through its left and right position.
As the virtual list keeps only a subset of its elements in the DOM the
":first-child" pseudo-selector no longer refers to the actual first
child element, but to the first one currently in the DOM; it would be
necessary to apply the CSS rules using a specific CSS class set only in
the desired element. However, as the first comment always includes the
date separator, which already has a top margin, the top padding is not
really needed in the first comment, so it was simply removed.
Moving the message list between the main view and the sidebar changes
its size, and thus it is necessary to reload the virtual list; when the
virtual list is reloaded it is ensured that the last visible element
will still be visible after the reload, so the chat view no longer needs
to explicitly handle that.
In a similar way, the message list also needs to be reloaded when the
window is resized, or when the chat view is in the main view and the
sidebar is opened or closed, as those actions change the size of the
main view.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The absolute position of the contacts menu is relative to the author
row, so it has to be pushed down to not overlap the author name and
avatar.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
The server does not provide default CSS rules for the contacts menu, as
its position depends on the element on which it is shown.
The contacts menu is now positioned to show the tip of the arrow
horizontally aligned with the center of the avatar, and with the top of
the menu slightly below the bottom border of the mention.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
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 selector does not match any element (it will do in the following
commits, but the rule would not be needed either), so it can be removed.
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>
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>
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>