Previously, there was no way to know for sure, if the currently selected
user and channel tree was being filtered. (in a screen reader context)
This commit switches the accessibleName depending on the channel filter
state.
Previously, screen readers would just read out the string of any selected
item in the tree.
With this new commit, the accessibleText and accessibleDescription are
set such that it is clear whether an item is a channel or a user and
which properties are set for both.
Fixes#2292
When clicking the "Start" button in the voice recorder dialog,
some random element receives focus automatically. Some or all
screen readers start reading the disabled options.
This commit automatically focuses the "Stop" button in the voice
recorder dialog when "Start" is clicked.
For some or all screen readers the "Next >" and "Back <" buttons
in wizards read out the ">" and "<" symbols which is rather annoying.
This commit explicitly sets the accessible name attribute such that
the buttons are read without the symbols.
Some or all screen readers are not associating the large description text
for the radio buttons in the quality page of the AudioWizard.
This commit explicitly sets the label content as the accessibleDescription
for the radio buttons.
The autocomplete function for usernames introduced in 56f5f978c
overwrites the forward-TAB accessibility behaviour. This results in
screen reader users being stuck inside the chat bar having to shift-TAB
or "back TAB" out to reach other user interface modules.
This commit changes the TAB autocomplete behaviour requiring an explicit
"@" in the chatbar for it to trigger. Otherwise it behaves as normal TAB.
See #5811
The second call to pa_context_subscribe() was overriding the first, as a result we were only receiving sink events.
This caused hotplugging to fail with devices that don't have any output ports (e.g. USB microphones).
In b5a67c0 a refactor took place which removed some compiler warnings.
In WASAPI.cpp a STACKVAR was swapped for a static std::vector,
which led to some unforeseen consequences and total audio input
failure on some systems.
This commit removes the static modifier as it is not needed there
anyway.
Fixes#6356
In 6c565689 the HostAddress was refactored. A check for isV6 when
creating a QHostAddress was removed. However, the QHostAddress
determines the (IPv4 vs IPv6) distinction at construction time.
This resulted in some regressions both visually and functional.
This commit reintroduces the distinction.
Fixes#6349
In the 'Messages' settings, when disabling a single notification method
for a single message type, all check-boxes will disappear in that
column if 'All messages' was checked to begin with. This is because the
automatic unchecking of the 'All messages' check-box is treated as
if the user actually clicked it. Using a QSignalBlocker before unchecking
the 'All messages' fixes the issue
Fixes#6302
In my previous PR (#6290) addressing this bug, I wrote:
> The issue seems to be caused by the scrollbar sometimes being in an
> inconsistent state immediately after a message is sent, but not any
> longer.
>
> My workaround is to add a call to QApplication::processEvents before
> setting the scrollbar to its maximum position to avoid the inconsistent
> state.
I have found that this change only reduces the likelihood of the
incorrect scroll behaviour from happening: it is still reproducible
after the log grows past a certain size.
In my testing since then, the cause of the "inconsistent state" described
previously seems to be the following: When images (whose contents are
stored in a base64-encoded data URL) are inserted into the log, they are
not loaded immediately. Instead, they are "fetched" (although no actual
network request occurs) by the `loadResource` implementation on
`LogDocument`. The "fetching" is triggered by the call to `setHtml` in
the `Log::validHtml` method. However, the code which sets the scroll bar
to stay at the bottom runs immediately (i.e. not asynchronously) in the
`Log::log` method. There also seems to be a hack that forces a re-layout
by sending a "font changed" event.
The intended behaviour appears to be that when a log entry is added the
log will scroll to the bottom if the entry is a message sent by the user
themselves, OR if the log was already scrolled to the bottom before
the entry was added.
The previous solution in place addressing the asynchronous image loading
was dispatching a `LogDocumentResourceAddedEvent` when the image is
loaded whose handler scrolls the log to the bottom, but this causes 2
problems:
First, the handler for this event always scrolls the log to the bottom
no matter what, which means messages containing images are handled
differently from the intended scrolling behaviour, i.e. messages
containing images ALWAYS cause the log to scroll to the bottom instead
of obeying the rules described above.
Second, it seemingly causes the issue described in #2504. It looks like
there's a race condition when the scroll position is set from the main
thread as well as in an event handler. I couldn't get to the bottom of
the exact source of the issue because there is so much deferred
execution going on, but I am confident that adding resources/forcing
re-layout events from an event handler is to blame.
My current solution is to remove as much of this asynchronous code as
possible. The use of a `QNetworkReply` seems to be leftover from when
Mumble supported remote images in chat. As described above, this
implementation was problematic and its complexity is no longer needed,
so I changed the implementation of `LogDocument::loadResource` to simply
check that the image URL is valid and has the `data://` scheme and then
just fall back to QTextDocument::loadResource`.
Implementing the solution this way eliminates the need for
`LogDocumentResourceAddedEvent` because everything happens in order as
expected and there is no need to "correct" the scroll value after the
image gets loaded. I therefore removed this class and the associated
code.
The default behaviour of `QTextEdit` is that it scrolls to the bottom
whenever contents are added. `LogTextBrowser::scrollLogToBottom` seems
to be a workaround to try to get the log to stay at the bottom despite
the scroll bar jumping issue. With my solution, this method can be
removed, and we only need to worry about "restoring" the previous scroll
value when a message from another user arrives and the log isn't already
scrolled to the bottom.
Currently translated at 100.0% (2156 of 2156 strings)
TRANSLATION: Update Chinese (Simplified) translation
Currently translated at 100.0% (2156 of 2156 strings)
TRANSLATION: Update Chinese (Simplified) translation
Currently translated at 100.0% (2150 of 2150 strings)
TRANSLATION: Update Chinese (Simplified) translation
Currently translated at 100.0% (2150 of 2150 strings)
Co-authored-by: Eric <zxmegaxqug@hldrive.com>
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: deluxghost <deluxghost@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/zh_Hans/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2156 of 2156 strings)
TRANSLATION: Update Swedish translation
Currently translated at 100.0% (2150 of 2150 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: bittin1ddc447d824349b2 <bittin@reimu.nl>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/sv/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2156 of 2156 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: John Doe <thraex@numericable.fr>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/fr/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2156 of 2156 strings)
TRANSLATION: Update Spanish translation
Currently translated at 100.0% (2153 of 2153 strings)
TRANSLATION: Update Spanish translation
Currently translated at 99.1% (2135 of 2153 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: gallegonovato <fran-carro@hotmail.es>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/es/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2156 of 2156 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2153 of 2153 strings)
TRANSLATION: Update Polish translation
Currently translated at 100.0% (2150 of 2150 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Matthaiks <kitynska@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/pl/
Translation: Mumble/Mumble Client
Currently translated at 99.7% (2150 of 2156 strings)
TRANSLATION: Update German translation
Currently translated at 98.2% (2118 of 2156 strings)
TRANSLATION: Update German translation
Currently translated at 98.1% (2117 of 2156 strings)
TRANSLATION: Update German translation
Currently translated at 98.3% (2115 of 2150 strings)
TRANSLATION: Update German translation
Currently translated at 100.0% (2110 of 2110 strings)
Co-authored-by: David <dawin@users.noreply.hosted.weblate.org>
Co-authored-by: Ettore Atalan <atalanttore@googlemail.com>
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Robert Adam <dev@robert-adam.de>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/de/
Translation: Mumble/Mumble Client
Currently translated at 100.0% (2156 of 2156 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: John Doe <thraex@numericable.fr>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/tr/
Translation: Mumble/Mumble Client
In 635d71960f cache invalidation for access tokens was added.
A check for ``uSource->iId >= 0`` was added which was intended
to only parse access tokens, if the ``authenticate`` method was
not returning an error code.
As it turns out though, ``uSource->iId`` will be -1 for unREGISTERED
users instead of unAUTHENTICATED users which lead to a bug
where unregistered users would not have the correct channel access
when connecting to the server. A subsequent update of their tokens
would fix that.
This commit moves the respective code block down and changes the
condition to ``ok``, which should now behave as originally intended.
Fixes#6334
The function was called "toggle*" and yet it didn't toggle anything but instead only acted as a setter for the respective property. Therefore, the naming has been adjusted accordingly.
The function was called "toggle*" and yet it didn't toggle anything but
instead only acted as a setter for the respective property. Therefore,
the naming has been adjusted accordingly.
QT invoke functions use the size_t type from std:: and some of the API functions that calls these invoke functions using the size_t type from the global namespace.This commit fixes the size_t type as std::size_t for these QT invoke functions.
To make the build reproducible, it's needed to set the timezone as
otherwise the date could vary based on the timezone of the build server.
Link: https://bugs.debian.org/1060254
QT invoke functions use the size_t type from std:: and some of the API
functions that calls these invoke functions using the size_t type from
the global namespace.This commit fixes the size_t type as std::size_t
for these QT invoke functions.
Co-Authored-By: Abdullah Ömer Yamaç <aomeryamac@gmail.com>
This commit refactors the code repeated in the main.cpp file.
Three connect functions were called with same parameters.
Co-Authored-by: Abdullah Ömer Yamaç aomeryamac@gmail.com
In b5a67c05f a buffer in the PulseAudio backend was made static, but
at the same time the memset(0) was removed.
In combination, that lead to a bug where the last few frames
of any given audio played back was repeated until something
else filled the buffer.
This commit adds a simple fill to the buffer where the memset(0)
previously was fixing the bug.
When selecting new public servers, we randomize their order. The random number used for that is an unsigned integer from which we compute the modulus with the list size in order to get a random index into the list.
This involved an implicit conversion from an unsigned integer (the random number) to a signed integer (the list index - as Qt uses signed integers for that). Thus, b5a67c0 added an explicit cast to a signed integer. However, it did this to the random number before the modulus operation, meaning that if a large enough random number is drawn, the cast would actually create a negative integer, yielding a negative list index after the modulus. This caused a crash of the application.
The fix consists in switching to using the bounded() function that has an overload for signed integers and which can directly generate numbers in the desired range, making all of the above superfluous.
Fixes#6306
When selecting new public servers, we randomize their order. The random
number used for that is an unsigned integer from which we compute the
modulus with the list size in order to get a random index into the list.
This involved an implicit conversion from an unsigned integer (the
random number) to a signed integer (the list index - as Qt uses signed
integers for that). Thus, b5a67c05fb added
an explicit cast to a signed integer. However, it did this to the random
number before the modulus operation, meaning that if a large enough
random number is drawn, the cast would actually create a negative
integer, yielding a negative list index after the modulus. This caused a
crash of the application.
The fix consists in switching to using the bounded() function that has
an overload for signed integers and which can directly generate numbers
in the desired range, making all of the above superfluous.
Fixes#6306
Co-authored-by: Thomas Lange <thomas-lange2@gmx.de>
