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>
Favourited conversations now show a favourite icon in the top right of
their avatar/conversation type icon in the conversation list.
The structure is based on the one used for the file list by the Tags
plugin of the Files app. However, the "favorite" icon was used instead
of the "starred" icon, as in this case it is just a mark that can not be
interacted with, and the "starred" icon changes its appearance on hover
and focus.
The mark can not be added as a child of the avatar/conversation type
icon, as it would be removed when the avatar is loaded. Therefore it is
a sibling of it placed on its top right corner using absolute
positioning.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before the public share auth page is rendered an event is dispatched
that can be used by apps to load additional scripts. This event is now
used to load the scripts that, when run on the browser, will inject the
Talk UI as needed in the page generated by the server.
The scripts will be loaded only when the share has the "send password by
Talk" option enabled; they add a button to the page that, when pressed,
creates a new public share auth room with the sharer and shows, in a
sidebar, the Talk UI for that room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "#content-wrapper" element was removed from the layouts provided by
the server; the "#content" element is now a direct child of the body and
a sibling of the header.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The sidebar trigger and fullscreen icons should have the same size as
the app navigation toggle (although the media icons are kept with the
same size as before). Note that this only reduces the visual size; the
touchable size is still 44x44px.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The icon to hide the video of a participant should have a reduced
opacity when the video is hidden/disabled, and when hovering or focusing
on it in that state it should be shown in full opacity, like done with
the own media icons.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the action is available but disabled hovering or focusing on a
media icon should show it in full opacity.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When local video was disabled all the media icons had a reduced opacity,
even if the audio or screensharing was enabled (in which case they
should have full opacity). This is fixed now by using two separate CSS
classes, "video-disabled" and "local-video-disabled"; the first is used
only on the video icon and controls its opacity like "audio-disabled"
and "screensharing-disabled" do for audio and screensharing icons, and
the second one is used in all the media icons and controls their colour.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The icons used for own media actions (muting, disabling the video or
screensharing) are usually white, except when there is no call, no
screensharing and no local video, in which case they appear on a white
background. In that case they should be black instead, so the default
white images are overridden with their black variant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The app navigation toggle, which is only shown in narrow screens, is a
dark icon defined in the server. During calls or screensharing the
background of the app content is set to black, so the icon was not
visible. Now the icon turns white in those cases, like the sidebar
trigger or the fullscreen icon.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The icons had full opacity during calls. Now they always have a reduced
opacity unless hovered/focused.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The server now provides an endpoint to generate white and black versions
of the same SVG icon. To easily use this it also provides a SASS mixin
that defines CSS variables with the path to each variant as well as CSS
rules with the background image for each variant of the icon.
The mixin is used now to define the icon for the sidebar trigger (the
fullscreen icon is defined in the server), and the CSS variables with
the path to the dark variant override the background image of the
otherwise white icons when not in a call or during screensharing.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The sidebar is no longer a child of the app content but a sibling, so
the selector for the rules that set the appearance of the sidebar
trigger when not in a call must be adjusted accordingly.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The entries in the search result and the room list are expected to start
with an ".avatar" element. When the entry is not a one-to-one
conversation an icon is shown instead of an actual avatar, but the
"avatar" CSS class (defined in the server) has to be used anyway to get
the expected layout.
In the room list the avatars are initialized only for one-to-one
conversations (so the width and height of the icon has to be set to 32px
to match the size of the actual avatars), but in the search result they
were initialized for every entry. When the user is undefined (that is,
when an icon is used) resolving the avatar caused an "Unknown user"
avatar to be generated and shown behind the icon; that avatar was hidden
by making its colour and background colour transparent.
Now the avatars in the search results are initialized only for
one-to-one conversations, so the colour hack is no longer needed
(although setting the size to 32px is).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The entries in the search result and the room list are expected to start
with an ".avatar" element. When the entry is not a one-to-one
conversation an icon is shown instead of an actual avatar, but the
"avatar" CSS class (defined in the server) has to be used anyway to get
the expected layout.
In the room list the avatars are initialized only for one-to-one
conversations, but in the search result they are initialized for every
entry. When the user is undefined (that is, when an icon is used)
resolving the avatar causes an "Unknown user" avatar to be generated and
shown behind the icon; that avatar is hidden by making its colour and
background colour transparent.
However, this was applied to all ".icon-contacts-dark" elements, not
only those in the search result, which caused the "Participants" text in
the tab header to be transparent and, therefore, invisible. Now the
colour hack is applied only to icons in the search result and in the
room list (which is not affected by the transparent text due to using a
different element for the text), which makes the tab header visible
again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As the sidebar is no longer a child but a sibling of app content and the
sidebar must be shown in fullscreen mode now the element that receives
the fullscreen mode is the main content, which is the parent of both the
app content and the sidebar wrapper. However, as it is also the parent
of the app navigation this now has to be explicitly hidden while in
fullscreen mode.
Due to the reorganization of the layout the header is no longer shown in
fullscreen mode, so there is no need to take it into account in the CSS
rules.
In a similar way, due to the changes in the layout the sidebar is no
longer shown by applying a margin to the app content, and the sidebar
now "pushes" the app content to the left when it is shown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
It is no longer needed to use an absolute position with a fixed width
for the input field for new conversations; the default CSS rules will
cause it to fill the navigation bar width.
As the input field now uses a static position it is taken into account
when calculating the position of the conversation list. Therefore there
is no need to use an extra top padding in the navigation bar.
Finally, the default bottom padding for the navigation bar is 0, so
there is no need to set it to that value.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The sidebar wrapper is now a flex container, which causes the trigger
and the sidebar to appear in columns, and thus ensures that the trigger
will be always shown next to the sidebar, no matter if it is shown or
hidden.
As the trigger is shown in its own column that column takes space and
pushes the app content to the left. To prevent this the trigger width is
removed from the sidebar wrapper by pushing its left margin, which
causes the app content to be next to the sidebar and the trigger to
appear in front of it (although the padding used in the chat view
prevents them from overlapping, just like before).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The z-index of the "#app-content" is now set in the server to 1000. Due
to the layout changes the trigger is now the child of a sibling of
"#app-content" instead of a descendant of "#app-content", so its z-index
must be higher than the one for "#app-content" to appear in front of it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Until now the public layout for guest users was based on the "base"
layout of the server, which was almost empty, and the "index-public"
template had to provide all the elements mimicking those used for public
pages in the server. The recent layout changes in the server have
introduced some structure changes in that base layout, which is now more
cumbersome to use with Talk.
Fortunately, in Nextcloud 14 a standard layout for public pages was
introduced, so now the public layout for guest users is based on that
public layout of the server instead. Therefore, it is no longer needed
to provide a header in the template, and the CSS rules used for the main
layout can be reused for the public layout.
There is a drawback, though; as the header is no longer a descendant of
"#app-content" it is no longer possible to make it transparent based on
the ".participants-XXX" classes set for that element. For now, and until
it is addressed, the header will still be visible during calls in guest
pages.
Also note that the public layout of the server does not provide at this
time a notification container, so that element must be kept.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Main layout elements (navigation, content and sidebar) are no longer
children of the "#app" element in the standard layout in the server, so
those changes are reflected in Talk too.
Note, however, that the "#app" element is still kept as an, in practice,
invisible element, as it is used as a holder for some values (like the
token or the signaling settings) used in scripts.
Besides that, although the layout of the server is mainly mimicked in
Talk, there are also some differences needed for its specific UI.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
System messages have no author, so instead of showing the date on its
own row and the message below it now the system message and the date are
merged in a single row using flexboxes.
When there is little available width the message and the date compress
each other and use several lines as needed. The width of the date is
limited to its content, while the message expands itself when possible,
which causes the date to be aligned to the right.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
System messages have no author, so the author row only contains the
date. As the date was shown using an absolute position it had no
influence on the width calculation of other elements and thus sometimes
overlapped them (for example, when a wide system message was shown in
the sidebar, but also if the user name was too long). Now the date uses
a static position with an automatic left margin, which in practice
causes it to be right aligned (both with and without author) due to
being a child of a flex display.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In older Firefox versions (like Firefox 47, the one used to run the
acceptance tests), when there are one or two participants in the call,
the video, avatar and media indicators of the local container appear
centered on the right edge of the app content wrapper. With more
participants in the call their position is the expected one.
Calls with one or two participants use a special layout to make the
local video larger, and in that case the local container children use an
absolute position which is relative to the app content wrapper (due to
the container also using an absolute position in that case instead of a
relative position like done when there are more participants).
For some reason (maybe related to the app content wrapper being a flex
box) their position is not properly calculated, so their alignment to
the right edge of the app content wrapper must be forced by setting
"right: 0" (which does not interfere with the layout in newer versions).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The default position (taking into account the CSS rules from the server)
of the menu in the room and participant lists shows the arrow aligned to
the center of the menu button. Moving it to the left is not needed, and
it causes the arrow to be no longer aligned with the center of the
button. Besides the contacts menu, which is already ignored in the CSS
rule, the other only element that has the "bubble" CSS class is the menu
in the participant list, so the rule can be safely removed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before a user could disable her own video, but she had no way to disable
the videos from other participants. This could be needed, for example,
to alleviate the load on low-end systems, as in that case playing the
video from remote participants could be too much for the system. Now a
toggle is provided to manually show or hide the video of each remote
participant if needed.
The toggle is shown only when the remote participant is sending video;
if the remote participant has disabled her own video (or does not have a
camera) the toggle is hidden.
Note that the toggle just shows or hides the HTML video element; it does
not notify the remote participant to mute her video or to fully stop
sending it. It is purely a local change that does not affect the remote
clients. In the future this could be extended to involve the remote
clients too, but for now just hiding the HTML video element notably
reduces the CPU load in most systems (although unfortunately in some
cases it does not).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Buttons with icons should have a size of 44x44px for easier interaction.
This matches the height of the participant list item in which the button
appears, and as such also centers the button vertically with the name of
the participant.
With the larger size the default grey background of the button is now
much more visible, but as the button has no border the background looks
strange. Due to this the background is removed, which also gives the
menu button in the participant list a consistent look with the menu
button in the room list.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The links in the tab header use an "icon-XXX" CSS class to define the
icon that is shown next to it; icons are defined using a
"background-image" CSS property in a ".icon-XXX" CSS selector.
The links in the tab header have their own CSS rules to place them in
the right position. Those CSS rules use a more specific selector than
the one used for the icons, so the CSS rules for the links in the tab
header override the CSS rules for the icons. Therefore, the
"background-repeat" and "background-position" properties must be
specified individually. Otherwise, if the general "background" CSS
property is used the "background-image" from the icon would be overriden
with a null image and thus no icon would be shown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When using Firefox, the participants tab view requires its overflow to
be hidden to limit its size to the size of its parents. Otherwise, the
participants tab view grows to fit its children; if that happens then no
scroll bar is shown for the participants list, as the participants list
is tall enough to fit all its items (even if they are not visible
because they are in the overflow area). In Chromium, on the other hand,
the participants tab view size is always limited by its parents, no
matter if the overflow is hidden or not.
In a similar way, once the overflow is hidden the bottom padding added
to the participants list has to be added to its last item instead.
Firefox only takes into account the bottom padding in the participants
list when the list has not overflown the participants tab view; it needs
to be added to the last item to be taken into account also when the
participants list is taller than the participants tab view. Chromium, on
the other hand, always takes into account the padding, no matter if it
is added to the participants list or to its last item.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Mentions in the public view and mentions in the new message form do not
show the contacts menu when clicked, so the cursor should be the default
one instead of the pointer cursor.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the chat view used the oldest on top layout the "oldestOnTopLayout"
CSS class was suppossed to be added to its main element. However, when
the "className" method was executed the "initialize" method had not been
executed yet, so there was no "_oldestOnTopLayout" attribute even if it
was included in the options, so the CSS class was never set and thus the
CSS rules were never used.
The support for the newest on top layout is going to be removed, and the
common CSS rules were already being used for the oldest on top layout
without problems; due to this, instead of fixing the setting of the CSS
class, the specific CSS rules for the oldest on top layout were simply
removed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Marco Ambrosini
Joas Schilling
Daniel Calviño Sánchez
Sascha Wiswedel
Joas Schilling
Ivan Sein
John Molakvoæ (skjnldsv)
Anton Stuetz
Jan-Christoph Borchardt
Joachim Bauch
Julius Härtl