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>
When the chat messages are shown from newest to oldest and a new message
arrives the list is automatically scrolled to keep the current visible
messages at the same place, except if the list was at the top, in which
case no scrolling is made and the new message appears.
When the chat messages are shown from oldest to newest and a new message
arrives the list is automatically scrolled to show the new message,
except if the list was not at the bottom in which case no scrolling is
made and the current visible messages are kept at the same place.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The header element contains the header div; as the header div uses a
fixed position the header element has no height, so an explicit height
was set for it to prevent "#app-content-wrapper" from overlapping with
the header element. However, as "#app-content-wrapper" has a 100% height
that caused the "#app-content-wrapper" to be moved 45px to the bottom,
and thus the chat view was partially cropped at the bottom.
When the chat view messages are shown from newest to oldest this causes
the first messages to be out of view, but when they are shown from
oldest to newest with the new message input at the bottom then the input
is partially out of view.
Now instead of giving the header an explicit height a "padding-top" is
set for the "#app-content-wrapper"; this prevents the contents from
being cropped while also preventing them from overlapping the header.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the tab contents were larger than the available space they were
limited to that space. Now, if the available space is larger than the
needed height the tab contents is also increased to fill it.
This ensures that the chat view will always stretch to the available
space, which in turn ensures that the "New message" input will be always
shown at the bottom of the sidebar like done in the main view (which was
not the case before when there were no messages or only a few).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before chat messages were shown from newest to oldest, with the new
message input above the list of messages. Now the layout can be chosen,
either the previous one or the reversed one, from oldest to newest with
the new message input below the list of messages.
The new reversed layout is the default one, and probably the old one
will not be used anywhere in the future... but for the time being I kept
the old one too just in case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Limiting the scroll bar in the sidebar to the list of chat messages
causes the scroll bar to be removed from the whole sidebar in other tabs
too. Therefore, the scroll bars must be explicitly enabled in the other
tab contents that need them.
The list of participants grows dynamically, so a vertical scroll bar
should be enabled on it to be able to view all the participants in a
long list.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Except when almost empty, the message list of the chat view is taller
than its available vertical space in the sidebar. Due to this a scroll
bar was shown for the whole sidebar, and everything was moved when
scrolling to see overflown messages. Now the scroll bar is shown only
for the message list, so it can be scrolled without moving the other
elements in the sidebar.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The lateral padding is the same used for the chat view when shown in the
sidebar (due to the padding from the tab itself). The same value was
used for the top padding to provide a consistent "frame".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When shown as the main view, the input field to add a new message is
always shown and a scroll bar is provided just for the list of messages.
Only the chat view is added and removed to and from the main view; the
other elements in the main view are not modified when that happens, and
they are hidden using some CSS magic.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The header element contains the header div; as the header div uses a
fixed position the header element has no height, so it must be
explicitly set to prevent #app-content-wrapper from overlapping with the
header element.
Right now it was not very noticeable, as it only affected the empty
content; as it name implies most of the space was empty except for a
message at the centre of the screen, so visually it did not overlap with
the header. However having a proper height set for the header will be a
must once the chat view is shown in the app content wrapper.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The submit confirm icon is shown as the background image of an
absolutely positioned input element, so the CSS rules for the submit
working icon were modified to match those of the submit confirm icon.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When two or more consecutive messages were sent by the same participant
with a difference of less than 120 seconds between each message those
messages are now shown grouped (the participant name is not shown for
the intermediate messages and each message is pushed closer to the
previous message).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The standard Nextcloud header is added automatically outside the
"#app-content" element when using the "user" template, so it is
automatically hidden when "#app-content" is set to fullscreen mode. The
public page uses the "base" template, so it has to provide its own
header element; this element appears inside "#app-content" (probably to
make it transparent using CSS rules during a call), so it has to be
explicitly hidden when in fullscreen mode.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The main room name element is now shown as "inline-block", which causes
the link icon to be placed next to it instead of below.
Due to the change from "block" to "inline-block" there is less available
width for the children input fields; the previous maximum width value is
now too narrow, so that limit to the width was removed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In normal mode (and a wide screen), when the sidebar is opened a
"margin-right" is applied to the app content to make room for the
sidebar. In fullscreen mode the element set as fullscreen is the app
content, but it seems that different browsers handle fullscreen elements
with a margin in different ways: Firefox ignores the margin and uses the
full width, while Chromium uses a strange mix which is neither the full
width nor the full margin. Due to this, now the margin is removed in
fullscreen mode to unify the appearance across browsers.
As there is no margin, the sidebar now visually seems to slide on the
app content instead of "pushing" it to the left (which is the same
behaviour shown in normal mode and narrow screens). Fortunately, this
behaviour fits well with the fullscreen mode, as the video is arguably
the reason to enter in fullscreen mode while the sidebar in this case is
probably just a temporal view that is closed most of the time.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of being based on the "participantTabView" id the CSS rules used
by the ParticipantView were modified to be based on its class,
"participantWithList". This will make possible to change the parent
element of the ParticipantView and keep its style.
The rules for links were merged as those links that required a padding
due to being shown with an icon were also those shown inside the list
items.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The right sidebar is an area that can be shown or hidden from the right
border of the document. It is a core element from Nextcloud, and
SidebarView is a Marionette wrapper around it. Therefore, it has to be
used along an "#app-content" element that takes into account the
"with-app-sidebar" CSS class.
However, this right sidebar extends the standard right sidebar with an
icon shown on the right border of the screen that makes possible for the
user to show it when hidden (as there is no other element in the UI
suitable for that purpose).
That icon is just a right-pointing triangle created with a CSS trick (a
zero-sized div with width borders, but all of them transparent except
for the left one). However, as the icon will be shown on different
coloured backgrounds it can not have just a single colour; it must
provide a border on its own too, which is achieved with another triangle
slightly larger underneath. The triangle border is 2px instead of just
1px used in other UI elements (like in the sidebar itself) to make it
more noticeable on a white background.
The triangle used for the icon is a large one, with a width of 24px and
a height of 48px. Using this trick has an added benefit, as its
clickable area is larger than the triangle itself (48x48px), which
improves its usability on touchable screens (and does not negatively
affect the experience on other devices).
Currently the SidebarView is empty. The content will be added in
following commits.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Daniel Calviño Sánchez
Joas Schilling
Ivan Sein
Jan-Christoph Borchardt
Joas Schilling
Joachim Bauch
Julius Härtl
John Molakvoæ (skjnldsv)
John Molakvoæ
Artur Bergen
Leon Klingele