The setting for keeping the local user always visible in the TalkingUI
was not put into effect immediately if the local user didn't happen to
be displayed in the TalkingUI at the time of applying the settings.
Instead the effect was only visible after a re-connect or after having
changed the local user's TalkingState so that it was added to the UI via
that route.
The fix was simply to add the user if it is currently not present but is
asked to be shown permanently.
The way TalkingUIContainer::updatePriority() worked prevented a
container's priority to decrease (even thought the entry because of which
the priority initially increased is no longer contained).
To fix this, the referenced function will now simply reset the cached
priority to the lowest possible value before performing the actual
checking.
On Linux (KDE Plasma) Qt (or rather the window manager) won't move a
widget off-screen so there was no need to check whether the position
saved for the TalkingUI was actually on-screen or not.
The situation seems to be a different one on Windows though. There it
can happen that the UI is moved off-screen. Once that happens the user
is more or less incapable of bringing it back again (as the saved
position won't get cleared).
In order to mitigate this issue, it is now (thoroughly) checked whether
or not the TalkingUI will end up on-screen or not.
The setting for keeping the local user always visible in the TalkingUI
was not put into effect immediately if the local user didn't happen to
be displayed in the TalkingUI at the time of applying the settings.
Instead the effect was only visible after a re-connect or after having
changed the local user's TalkingState so that it was added to the UI via
that route.
The fix was simply to add the user if it is currently not present but is
asked to be shown permanently.
On Linux (KDE Plasma) Qt (or rather the window manager) won't move a
widget off-screen so there was no need to check whether the position
saved for the TalkingUI was actually on-screen or not.
The situation seems to be a different one on Windows though. There it
can happen that the UI is moved off-screen. Once that happens the user
is more or less incapable of bringing it back again (as the saved
position won't get cleared).
In order to mitigate this issue, it is now (thoroughly) checked whether
or not the TalkingUI will end up on-screen or not.
The way TalkingUIContainer::updatePriority() worked prevented a
container's priority to decrease (even thought the entry because of which
the priority initially increased is no longer contained).
To fix this, the referenced function will now simply reset the cached
priority to the lowest possible value before performing the actual
checking.
This allows:
- The client to find servers advertized via zeroconf without the need for Bonjour to be installed.
- The server to advertize itself via zeroconf without the need for Bonjour to be installed.
The Win32 API was introduced in the version 10.0.18362.0 (1903/19H1) of Windows SDK. Before that, only the UWP interface was available (introduced in Windows 10 1507).
This commit was successfully tested on Windows 10 1809, which probably means that the API can be used on previous versions as well.
Even if that isn't the case, it's not a problem: if the code fails to load the required symbols, it falls back to Bonjour.
"Q_OS_WIN64" is used instead of "Q_OS_WIN" because of an issue that appears when certain DNS functions are used in an x86 (32 bit) build: https://developercommunity.visualstudio.com/content/problem/1191345/some-dns-api-functions-cause-lnk2019-errors-in-32.html
This means that until the issue is fixed we can safely use the native mDNS-DNS-SD API only on x86_64 (64 bit).
This should make it more clear that we don't include Bonjour-related stuff in our project. We use external libraries depending on the OS.
For compatibility, the server option is still called "bonjour". We should probably add a new option called "zeroconf" and then handle the old one if present in the configuration file.
If a sound-file failed to load, there is no hint about this in the logs
or anywhere else as it never actually gets ensured that the loading was
successful.
Now and explicit check is performed and if the loading failed, a warning
is printed to the console.
Closes#4492
If a sound-file failed to load, there is no hint about this in the logs
or anywhere else as it never actually gets ensured that the loading was
successful.
Now and explicit check is performed and if the loading failed, a warning
is printed to the console.
Closes#4492
Before the overlay libraries and the related script would not be
installed. Instead the user would have to manually install them on the
system.
Now the overlay libraries are added to the install. The script was fixed
to take into account the correct overlay library names.
Closes: #4471
Before the overlay libraries and the related script would not be
installed. Instead the user would have to manually install them on the
system.
Closes: #4471
The overlay script did not use the current library names of the overlay
libs. So when installing, the libraries had to be renamed or the script
edited for it to work.
PR #4487 introduced a regression in form of a failing assertion in case
a user has stored volume adjustments for a ChannelListener in its DB. In
that case the client would crash as soon as the server-connection has
synchronized.
The issue was caused by a change-event being emitted before the
ChannelListener officially existed. The fix is to simply not send these
events in the first place.
PR #4487 introduced a regression in form of a failing assertion in case
a user has stored volume adjustments for a ChannelListener in its DB. In
that case the client would crash as soon as the server-connection has
synchronized.
The issue was caused by a change-event being emitted before the
ChannelListener officially existed. The fix is to simply not send these
events in the first place.
This is a followup on #4439 (and #4436) that fixes 2 issues of that implementation:
Wrong volume adjustments being displayed for ChannelListeners in certain situations
MainWindow not updating automatically when the adjustments change
If the local volume adjustment of a client or a ChannelListener was
changed, the MainWindow would not reflect this change until some event
triggered it to refresh (e.g. MouseOver).
With this fix, the MainWindow gets updated immediately when the volume
adjustment is changed (of a client or a ChannelListener).
The local volume adjustment a user has set for their own
ChannelListeners would be displayed for all listeners in that channel
(even for the listeners of other clients).
This has been fixed by making sure these adjustments are only displayed
for local listeners.
This could also cause a crash, in case gswForward() was called before GlobalShortcutsWin's initialization.
For reference, the bug was introduced in 01db6e219d.
Compiling with Boost a somewhat recent version of Boost would produce
warnings about deprecated usage of boost::bind.
These have been fixed now.
The warning was
The practice of declaring the Bind placeholders (_1, _2, ...) in the
global namespace is deprecated. Please use
<boost/bind/bind.hpp> + using namespace boost::placeholders, or
define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.
Fixes#4295
Compiling with Boost a somewhat recent version of Boost would produce
warnings about deprecated usage of boost::bind.
These have been fixed now.
The warning was
The practice of declaring the Bind placeholders (_1, _2, ...) in the
global namespace is deprecated. Please use
<boost/bind/bind.hpp> + using namespace boost::placeholders, or
define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.
Fixes#4295
We used the BUILD_TESTING variable in order to indicate whether or not
tests shall be built. However this variable is used by e.g. CTest
already and there it had a different default value. Therefore we now
deprecate BUILD_TESTING and use the tests option instead.
The used .clang-format file has been generated using clang-format 6
(shipped with Ubuntu 18.04) and is therefore backwards compatible with
all clang-format versions until v6.
The used .clang-format file has been generated using clang-format 6
(shipped with Ubuntu 18.04) and is therefore backwards compatible with
all clang-format versions until v6.
Mumble usually ships with all its plugins in /usr/lib/mumble/* but the
new make install target installs them directly into /usr/lib/*.
This however can lead to certain files being overwritten.
Therefore these paths are changed in order to install these libraries
into /usr/lib/mumble/* again.
Fixes#4477
We used the BUILD_TESTING variable in order to indicate whether or not
tests shall be built. However this variable is used by e.g. CTest
already and there it had a different default value. Therefore we now
deprecate BUILD_TESTING and use the tests option instead.
This also fits better with our other options in terms of casing.
The TestServerResolver test requires an active internet connection. This
is something that is not really expected when running the tests and will
cause test failure if used without an internet connection.
Therefore this commit makes this test optional. By default this test
will not be built. If you want to enable it (and potential future
tests that require an internet connection), you have to use
-Donline-tests=ON when invoking cmake.
