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>
The edit button of editable text labels is always hidden, except when
the cursor is on the editable text label. Due to this the step to rename
a conversation first clicked on the editable text label and then, given
that it was now visible, on the edit button.
Before clicking on an element the cursor is moved to the middle of that
element, and due to the layout changes, it turns out that the edit
button is now at the middle of the editable text label; when the cursor
was moved the edit button was shown and it ended receiving the click
instead of the editable text label. This caused the editable text label
to enter in edit mode, so the edit button was hidden, and then it could
not be clicked in the next action as expected.
Now only the label element is clicked instead of the containing editable
text label; as the label element is a sibling of the edit button shown
next to it and both are children of the editable text label this causes
the edit button to be shown in the first action and then clicked in the
second action, just like before.
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 specification of acceptance tests for chats do not take into account
the system messages, so now the selector for chat messages filters them
out and leaves only messages sent by users.
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>
The sidebar is now a sibling instead of a child of "#app-content" in the
standard layout in the server, so that is reflected in Talk too.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>