As it is a boolean flag just set once and only needed when the current
user is a guest an implicit attribute added dynamically is now used
instead of an explicit attribute; "_" was prepended to the name too to
mark it as "private".
Note that in the embedded Talk UI there was no explicit attribute, so
the condition would have never passed and the hint would have never been
shown. However, as the embedded Talk UI is currently not used with
guests it was not an issue.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In the embedded Talk UI the local video container is not hidden, so
there is no need to remove its "hidden" CSS class when the local media
is started.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the audio is set as available it is followed by a call to
"setAudioEnabled(bool)", so the state of the audio button just set was
always immediately overriden. Moreover, as only the button state but not
the related attribute was set the view was left in an inconsistent
state.
It is currently not possible to directly call "setVideoEnabled(bool)"
from "hasVideo()", so for consistency both "hasAudio()" and "hasVideo()"
expect "setXXXEnabled(bool)" to be explicitly called after they are
called.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The audio and video are explicitly set as disabled before they are set
as not available, so there is no need to set them as disabled again.
Moreover, even if they were not explicitly set as disabled it would not
be really necessary to disable the audio and video when they are not
available.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The condition passes when the video is available, but it will only be
executed anyway if the video is available due to the initial condition
in the method.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The proper name was being used in the "constructor" to initialize the
attributes to false, but not in the rest of the file; this caused the
attributes to be undefined when they were first used, which
coincidentally in those cases it was the same as if they were false, so
the typo caused no issues.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When calling "disableVideo" the video was hidden even if it was not
possible to disable the video; this was done to hide the video even if
WebRTC was not started yet when "disableVideo" was called. Now that the
video is disabled when joining the call in a room with more than five
participants instead of just when entering a room with more than five
participants that special behaviour is no longer needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Until now, when entering a room with more than five participants the
video was disabled. However, if the local video is available it is
enabled when WebRTC starts. Due to this, if WebRTC was also started when
joining the call (that is, no previous calls were made in other rooms
since the last page reload) the video was enabled instead of disabled.
Besides that, if leaving the call with the video enabled and joining it
again the video was still enabled, as the room had not been entered
again to disable the video. To fix both issues now the video is disabled
when joining the call instead of when entering the room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>