"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>
The contacts menu is not shown in the public view for any user, so the
default cursor should be used for all the author rows.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that "currentUser" is not set in the author row of guest users, but
this is not a problem; that CSS class is used only to show the default
cursor instead of the pointer cursor, but as all the author rows of
guest users show the default cursor it makes no difference if
"currentUser" is set for them or not.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of adding the "currentUser" CSS class to ".avatar" and ".author"
elements now it is added to their wrapping ".authorRow" element.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a message shows the date separator its author row is explicitly
shown. This is needed to ensure that the author row will always be shown
in that case, even if the message is a grouped message. In normal
messages (those that are not grouped and do not show the date separator)
the author row is shown using "display: inline-flex", so the same value
should be used too for messages that show the date separator.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a message is being sent the submit icon is hidden and the working
icon is shown instead. However, the working icon was not placed at the
same position as the icon it replaced; the CSS rules for the submit icon
were modified in some previous commit, but the CSS rules for the working
icon were not appropriately updated. Now the CSS rules were rewritten so
both elements use the same placement rules; this fixes the issue and
should make it less likely to happen in the future if the placement is
modified again.
Also, now the size is explicitly set to ensure that both elements have
the same size; before it depended on other rules, and which rules
affected the size were different for each element due to being of
different types.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
CSS styles were directly copied from
"apps/comments/css/autocomplete.scss".
JavaScript code in the chat view
was slightly simplified from "apps/comments/js/commentstabview.js".
Currently mentions are not formatted when a message is being composed;
"@" followed by the user name is added to the message so it can be
directly sent without further processing. Formatted mentions will be
introduced in another commit.
Signed-off-by: Joas Schilling <coding@schilljs.com>
Clicking on a message author shows the contacts menu (provided the
author is not the current user); in those cases the cursor should be a
pointer so the user knows that an interaction with those elements is
possible.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
A pointer cursor is now used on mentions to make the user aware of a
possible interaction. As the contacts menu is not shown for mentions of
the current user the default cursor is kept in that case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The contacts menu expects its parent element to be its positioning
context, so the mention must have a relative position. Besides that, the
default CSS rules from the server set the position of the contacts menu
assuming that the parent element is an avatar, so the rules have to be
overriden to position it on the text.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The border-box sizing is set for apps in the server, but the CSS rules
for the icons of the contacts menu (also set in the server!) assume that
content-box sizing is used. Therefore the proper size should be forced
for the icons to be visible.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The contacts menu uses both the "bubble" and "contactsmenu-popover" CSS
classes, and the specific rules for ".bubble" elements used in Talk
should not affect the contacts menu.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In some cases (like when LDAP is being used) a user can not be easily
identified through its user name (as it is just a hash), so formatted
mentions now show the display name in all cases (and if the server does
not provide a display name the "name" parameter of the template falls
back to the user name).
Note that the acceptance tests do not need to be updated, as the
display name of the mentioned user is the same as its user name.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The RichObjectStringParser was copied from the Notifications app and
adapted to be used in the chat (support for file references was removed,
"-" is taken into account too in parameter IDs, only local users are
taken into account, and if the display name of a mention is empty the
user ID is used instead).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>