| Age | Commit message (Collapse) | Author |
|---|
|
nextcloud/feature/5452/add-create-conversation-button-if-public
Add create conversation button
|
|
Signed-off-by: marco <marcoambrosini@pm.me>
|
|
Signed-off-by: marco <marcoambrosini@pm.me>
|
|
nextcloud/bugfix/5776/fix-video-toggling-on-pasting
Fix video toggling on pasting
|
|
nextcloud/bugfix/4921/show-description-and-relative-lobby-time
Add description and relative lobby timer on lobby screen
|
|
Signed-off-by: marco <marcoambrosini@pm.me>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Improve ESLint part 2
|
|
nextcloud/bugfix/noid/dont-overwrite-selected-devices-when-there-is-only-one
Don't save device selection when there is only one device
|
|
This will allow a laptop to recover after being disconnected from
a docking-station for one call and being docked afterwards again
to use the previous selected device again.
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: marco <marcoambrosini@pm.me>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Rename language strings to camelCase
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
This reverts commit 81d76dde09a89a68b113a0288583c964d13b8758.
The changes were needed due to the chat view having an absolute
position. Since Talk 12 that is no longer the case, so these changes
just caused an unneeded margin.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
nextcloud/work-around-chromium-bug-of-iceconnectionstate-stuck-as-disconnected
Work around Chromium bug of iceConnectionState stuck as "disconnected"
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Due to a bug in Chromium the "iceConnectionState" of a RTCPeerConnection
may get stuck as "disconnected" even if the connection has already
failed. However, in that case "connectionState" does change to "failed",
so now its listened too to changes in "connectionState" to handle that
case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
nextcloud/bugfix/noid/log-device-selection-falling-back-and-also-try-by-label
Add some logging to the device selection
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Otherwise the first device found would be used even if a "default"
device was found later.
In practice this may not be needed, as Chromium seems to always list the
"default" device first if it is available, but just in case.
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
nextcloud/fix-laggy-high-resolution-videos-in-chromium
Fix laggy high resolution videos in Chromium
|
|
Chromium does not allow to increase the resolution of a video stream
once the video stream is cloned. If a video stream is requested without
any constraint, the video stream is returned with a resolution around
640x480. Therefore, when Chromium is used the streams needs to be
explicitly requested with a high resolution to be able to increase the
resolution later as needed.
As the requested resolution is a loose constraint the resolution was
requested as 1920x1200 instead of the more common 1920x1080 to try to
cover most cases. However, if a camera does not exactly provide
1920x1200 but 1920x1080 and also an even higher resolution Chromium may
choose to crop and scale that higher resolution video rather than using
the 1920x1080 video.
The problem is that Chromium may choose to do that even if the higher
resolution video has an incredibly low frame rate (for example, Chromium
is able to get 2304x1296 and 2304x1536 videos from the Logitech C920,
but only at 2 FPS). Moreover, it seems that once the stream is cloned
Chromium is not able to then get a lower resolution but higher frame
rate video; it seems to be stuck with the original stream and just scale
it as needed, so the lower frame rate is still kept.
To fix this now the initial stream is requested with both a high
resolution and a high frame rate. This way Chromium needs to balance
both constraints and thus provide a video without the highest resolution
but with an acceptable frame rate.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
nextcloud/fix-container-of-modal-and-popup-components-when-talk-is-embedded
Fix container of modal and popup components when Talk is embedded
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Using the default container causes the action menus in the Talk tab to
be repositioned at wrong places when the menus are shown and the file
list is scrolled. To address this (although it does not fully fix the
issue, there are still some strange behaviours) the main container for
Talk components used when Talk is embedded in the Files app is Talk tab.
Besides that, both the container and the boundaries element of the
actions are set to the Talk tab.
Despite setting the main container this change does not affect other
components (like the room selector) or slightly improves their behaviour
(like the author avatar menu, which no longer appears outside the tab
when scrolling).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
⭕ Circle tracking
|
|
nextcloud/fix-connection-quality-warning-still-shown-after-media-is-stopped
Fix connection quality warning still shown after media is stopped
|
|
The container of modal and popup components was always set to
"#content-vue" to ensure that they will be properly shown in normal and
fullscreen mode in the main Talk UI. However, when Talk is embedded in
the Files app, the share page or the video verification there is no such
element, so the container for the components could not be set and thus
they were not shown.
To solve this now the selector for the main container element is got
from the store instead of being hardcoded, and the different UI modes
set the appropriate value when initialized (or leave it undefined to use
the default one, typically the body element, when a specific element is
not needed).
Note that this change applies too to some components that, right now,
are only shown in the main Talk UI, but it was done for consistency and
to make them "future-proof".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
The forward action shows the RoomSelector, which fetches the room
list, but that is not allowed for guests.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
When the audio/video or the screen peers were cleared the connection
quality data was not reset. Due to this the connection quality warning
would be kept shown if, for example, the screen share was stopped while
the warning was being shown.
For simplicity and consistency the connection quality data is reset too
when a different peer connection is set (not just when it is cleared),
although this is not really needed as the previous connection quality
was already cleared in that case further in the code path.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
nextcloud/fix-duplicated-registration-of-audio-encoder
Fix duplicated registration of audio encoder
|
|
nextcloud/fix-infinite-loop-when-the-constraints-can-not-be-decreased
Fix infinite loop when the constraints can not be decreased
|
|
Signed-off-by: Christopher Ng <chrng8@gmail.com>
|
|
The minimum value of the constraints was wrongly capped using "min"
instead of "max", so in practice the first time that the value was
decreased it was already set to the minimum capped value. Moreover, if
the value could not be set the minimum value could be decreased in the
next iteration even below the capped value.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The previous minimum frame rate was wrongly got from the maximum frame
rate, so when the minimum frame rate was compared after decreasing it it
was always seen as changed. Due to this the constraints will be applied
again even if they did not actually change due to having reached the
minimum capped value, which would end in an infinite loop if the
constraints could not be applied and the minimum frame rate was (tried
to be) decreased again.
However, note that the scenario above was unlikely to happen in the real
world, as the browsers would likely accept the minimum capped value for
the frame rate of 1. The problem would occur if the stream did not come
from a device (even virtual ones) but from an HTML canvas or something
similar that does not allow to change the constraints.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The audio encoder is initialized when the AudioRecorder component is
mounted, and the store keeps track of whether the audio encoder was
already initialized to not do it again.
However, the audio encoder was also unconditionally registered in the
main components of the main and sidebar Talk UIs, which caused a
duplicated registration when the audio encoder was initialized (as the
store did not "know" that it was already registered).
Due to all this the unconditional registration is removed (which also
avoids registering the audio encoder when it will not be needed, like
when the current user is a guest without upload permissions).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
