Received compiler warning of an assert that is always true.
The assert checked if variable is negative but it is an unsigned variable.
Just check if positive.
Having plain http as the default means that a site, even though able to support https, will be able to fall back to using the insecure and outdated protocol.
Furthermore, major browsers already support https by default, falling back to legacy http in the cases where a website does not support https connections, e.g. Chromium, Firefox.
Therefore, this commit makes it so that a link without a protocol specification will have https:// prefixed to be clickable instead of http://.
As reported in #4491, #4986 and #5430, since the changes to the chat in
the 1.4.x release, some tags would "pollute" the rest of the log, i.e.
cause future log entries to be contained within them.
The source of the issue seems to be that the insertBlock method of
QTextCursor appears to correspond to the <p> HTML tag. The <p> tag
may only contain inline elements, but QTextEdit will not fail outright
when inserting block-level elements and will instead attempt to correct
the invalid input which results in the behaviour reported in the above
issues (as far as I can tell).
The proposed solution is to use the insertFrame method for all
messages.
Fixes#4491
Having plain http as the default means that a site, even though able to support
https, will be able to fall back to using the insecure and outdated protocol.
Furthermore, major browsers already support https by default, falling back to
legacy http in the cases where a website does not support https connections,
e.g. [Chromium](https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html),
[Firefox](https://blog.mozilla.org/security/2021/08/10/firefox-91-introduces-https-by-default-in-private-browsing/).
Therefore, this commit makes it so that a link without a protocol specification
will have `https://` prefixed to be clickable instead of `http://`.
Signed-off-by: mataha <mataha@users.noreply.github.com>
As reported in #4491, #4986 and #5430, since the changes to the chat in
the 1.4.x release, some tags would "pollute" the rest of the log, i.e.
cause future log entries to be contained within them.
The source of the issue seems to be that the `insertBlock` method of
`QTextCursor` appears to correspond to the `<p>` HTML tag. The `<p>` tag
may only contain inline elements, but `QTextEdit` will not fail outright
when inserting block-level elements and will instead attempt to correct
the invalid input which results in the behaviour reported in the above
issues (as far as I can tell).
My proposed solution is to use the `insertFrame` method for all
messages.
Fixes#4491
Without this, building against the latest poco snapshot results in errors like:
/usr/bin/ld: /builddir/build/BUILD/mumble-1.4.230.src/src/mumble/PluginManifest.cpp:72: undefined reference to `typeinfo for Poco::XML::Element'
Without this, building against the latest poco snapshot results in
errors like:
/usr/bin/ld: /builddir/build/BUILD/mumble-1.4.230.src/src/mumble/PluginManifest.cpp:72: undefined reference to `typeinfo for Poco::XML::Element'
The automatic upgrade from VS2019 to VS2022 broke our build and in order
to prevent that in the future, we now pin the used VS version to 2022.
Later upgrades will have to be performed explicitly.
The automatic upgrade from VS2019 to VS2022 broke our build and in order
to prevent that in the future, we now pin the used VS version to 2022.
Later upgrades will have to be performed explicitly.
Previously Mumble was using a custom binary format for transmitting data
via UDP (mainly audio). This has worked for a long time but besides
being inconvenient for 3rdParty implementors (they had to manually
re-implement encoding and decoding support for this format) this format
was not very flexible and changes to the data format were very hard.
In order to improve on this situation, this commit introduces changes
that allow to use Protobuf for the UDP messages as well (it's already
used for TCP). With that it should be relatively easy to extend/change
the UDP packet formats in the future and 3rdParty implementors can now
simply use Protobuf to handle decoding/encoding packets for them (much
less work and much less prone to errors).
Since the new Protobuf format is incompatible with the old UDP format,
this commit also includes support for dealing with older clients or
servers that don't recognize the new protocol yet. That way the new
protocol format is only used if both the client and the server are
recent enough to have it implemented (assumed to be the case >=1.5.0).
Note also that the server will make sure that clients using the old and
the new format can seamlessly communicate with one another.
Therefore, on the surface it should not be noticeable to the user which
protocol is currently used.
Note also that the new protocol format only supports Opus as an audio
codec. If one of the legacy codecs is to be used, the legacy packet
format has to be used as well. However, all codecs except for Opus will
be removed from Mumble in the future anyway.
Fixes#4350
NOTE: When this gets merged, all clients and servers claiming to support the protocol version 1.5.0 that do not include these changes, will become incompatible with the ones that do integrate these changes. This is important for everyone closely following our upstream master branch. A simple update to the latest code changes (including the changes from this PR) should be enough to restore full compatibility.
All servers and clients of version < 1.5.0 will be not affected by this as this PR is completely backwards compatible with those clients.
The update includes the changes made to the upstream code since 2016
plus an additional fix for a memory leak encountered in Mumble's usecase
(in the new audio cache implementation introduced with switching Mumble
audio to the Protobuf format).
This message type is explicitly handled before calling into the
different msg* implementations. Therefore, msgUDPTunnel could never be
called in the current state of the code base.
However, we can't remove the implementation completely, because of the
macro voodoo that is used to declare and switch over the different
message types (we can't remove the entry from the macro, since in there
we still need it for defining the respective enum entry).
Previously the opusthreshold config option had a default value of 100
meaning that the first non-Opus client would cause everyone to fall back
to one of the legacy codecs.
Since Opus has been implemented for ages now and we eventually want to
get rid of the legacy codecs, this commit changes the default value of
this config option to be zero, meaning that the server will always
enforce the use of the Opus codec (regardless of what clients are
connected).
Previously Mumble was using a custom binary format for transmitting data
via UDP (mainly audio). This has worked for a long time but besides
being inconvenient for 3rdParty implementors (they had to manually
re-implement encoding and decoding support for this format) this format
was not very flexible and changes to the data format were very hard.
In order to improve on this situation, this commit introduces changes
that allow to use Protobuf for the UDP messages as well (it's already
used for TCP). With that it should be relatively easy to extend/change
the UDP packet formats in the future and 3rdParty implementors can now
simply use Protobuf to handle decoding/encoding packets for them (much
less work and much less prone to errors).
Since the new Protobuf format is incompatible with the old UDP format,
this commit also includes support for dealing with older clients or
servers that don't recognize the new protocol yet. That way the new
protocol format is only used if both the client and the server are
recent enough to have it implemented (assumed to be the case >=1.5.0).
Note also that the server will make sure that clients using the old and
the new format can seamlessly communicate with one another.
Therefore, on the surface it should not be noticeable to the user which
protocol is currently used.
Note also that the new protocol format only supports Opus as an audio
codec. If one of the legacy codecs is to be used, the legacy packet
format has to be used as well. However, all codecs except for Opus will
be removed from Mumble in the future anyway.
Fixes#4350
ght now we are using osxdist.py to generate a DMG package from scratch.
The script also takes care of signing the content.
However, our mumble-releng repository has had a dedicated script called sign-dmg.py since 2013.
In fact, that's what we have always been using to sign the app bundle.
As we're planning to eventually ditch osxdist.py in favor of CPack's generator, we decided to complete sign-dmg.py.
The script now:
Takes care of signing all binaries in the bundle in addition to it, effectively replacing osxdist.py.
Supports single binaries, replacing sign-mach-o.py (which only called codesign() from sign-dmg.py).
Supports PKG packages.
Provides a --config option to specify the path to the configuration file. Default: $HOME/.sign_macOS.cfg.
Provides a --entitlements option to specify the path to the plist file containing the requested capabilities.
This is mandatory for notarization to succeed. More specifically, the --options runtime codesign parameter is.
The parameter is not passed if this option is not used because it would cause Mumble to crash upon audio input use.
The name is changed to sign_macOS.py as the script does not only handle DMG packages anymore.
In the server browser, the tooltip for the different entries shows the
packet loss. It is displayed as a percentage and as a x/y stat. The
latter currently displays <received>/<sent> which is very confusing,
given that the title for that row is "Packet loss" implying x would
describe the lost packages instead of the received ones.
Thus this commit changes this to the expected behavior. Furthermore it
makes sure that <lost> is always <= <sent>.
Besides the typedef that is meant to be used in code, there is also one
that encodes a type of the exact size (32bit) a raw version is expected
to have.
The "Guidelines Support Library" (GSL) is a library that implements
functions and types suggested by the C++ Core Guidelines. This should
make it relatively straight forward to follow these guidelines and thus
to write better C++ code.
This explicitly adds the Microsoft GSL as that seems to be the most
popular (and complete) GSL implementation available.
Currently translated at 100.0% (2088 of 2088 strings)
TRANSLATION: Update German translation
Currently translated at 100.0% (2086 of 2086 strings)
TRANSLATION: Update German translation
Currently translated at 100.0% (2080 of 2080 strings)
TRANSLATION: Update German translation
Currently translated at 100.0% (2080 of 2080 strings)
TRANSLATION: Update German translation
Currently translated at 99.9% (2079 of 2080 strings)
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 12.7% (267 of 2086 strings)
TRANSLATION: Update Catalan translation
Currently translated at 12.7% (266 of 2086 strings)
TRANSLATION: Update Catalan translation
Currently translated at 9.1% (190 of 2086 strings)
TRANSLATION: Update Catalan translation
Currently translated at 4.1% (86 of 2080 strings)
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Konstantin Goncharik <botankras@gmail.com>
Co-authored-by: Omar Macías Molina <omar.maciasmolina@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/ca/
Translation: Mumble/Mumble Client
Currently translated at 99.6% (2078 of 2085 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.6% (2073 of 2080 strings)
TRANSLATION: Update Russian translation
Currently translated at 99.6% (2073 of 2080 strings)
Co-authored-by: Game one <denis.melnyk.2006@gmail.com>
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Konstantin Goncharik <botankras@gmail.com>
Co-authored-by: Nikita Epifanov <nikgreens@protonmail.com>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/ru/
Translation: Mumble/Mumble Client
Currently translated at 96.9% (2022 of 2086 strings)
TRANSLATION: Update Swedish translation
Currently translated at 97.3% (2024 of 2080 strings)
Co-authored-by: Allan Nordhøy <epost@anotheragency.no>
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Co-authored-by: Shjosan <shjosan@kakmix.co>
Translate-URL: https://hosted.weblate.org/projects/mumble/mumble-client/sv/
Translation: Mumble/Mumble Client
