This fixes a problem with MinGW on Linux where it can't find the icon file, because of the backslashes.
Windows handles the path correctly with both methods.
This fixes a problem with MinGW on Linux where the "win32" block is triggered and the two backslashes are used, resulting in a path without slashes.
Python on Windows handles the path correctly with both methods.
It is unnecessary (the system has window-hiding built-in) and
can get us in a state where the window can't be shown again.
Easier just to leave it out.
The API of QSslDiffieHellmanParameters is frozen and will be available
in Qt 5.8.0.
Remove the safety-net of only allowing QSslDiffieHellmanParameters for
Mumble build environments.
Without this, we delay the log messages from -limits
until we exit with a qFatal.
This isn't good, because -limits *can* fail in ways that
cause it to get stuck. One example of this is when Murmur
runs out of memory. This typically happens on 32-bit systems
during the test that counts the number of threads Murmur can
spawn, given the system's resource limits.
One such instance is if we reach the virtual memory limit on
i386. Then, QThread::start() will try to call pthread_create(),
which fails with EACCESS. (Insufficient resources, system-imposed
or otherwise). Qt doesn't handle this error situation, but
instead calls qWarning to make the user aware.
Without this change, we would never present this warning to
the user, because Murmur would be stuck.
With this change, the user can at least see the warning, to
know something has gone wrong.
Fixesmumble-voip/mumble#2752
This commit documents the intent behind Audio::stopInput(), Audio::stopOutput() and Audio::stop().
Namely that the functions are coded the way they are to guarantee deterministic destruction of
AudioInput/AudioOutput on the main thread.
It also adds documentation to the AudioInput and AudioOutput constructors and destructors that
spells out the guarantee that they can only ever be called on the main thread, and only by
the Audio::startInput(), Audio::startOutput(), Audio::start(), Audio::stopInput(), Audio::stopOutput()
and Audio::stop() methods.
This reverts PR #2674. That PR has a bug in stop(), stopInput() and stopOutput().
Specifically, the original code was structured such that destruction of
the AudioInput and AudioOutput objects would happen inside any of the stop methods.
However, the new implementations of stop(), stopInput() and stopOutput() in PR #2674
could cause the AudioInput and AudioOutput objects to be destroyed at any site that
takes a copy of g.ao or g.ai.
This happened in the PulseAudio backend. The AudioInput destructor would be called
while holding the PulseAudio mainloop lock. The destructor of the Pulse backend's
AudioInput also, tries to take the PulseAudio mainloop lock, causing an abort() to
happen.
Let us revert PR #2674 for now. There is no obvious way to implement the controlled
destruction behavior of the boost::shared_ptr with QSharedPointer. We also don't have
any code in Mumble that requires the audio shared pointers to be atomic (which was the
reason for the PR in the first place).
Fixesmumble-voip/mumble#2745
The protoc compiler in protobuf 3.x.y complains (warns) about
Mumble.proto not explicitly specifying a syntax. This commit
fixes that.
The syntax=XXX declaration is mentioned in language spec for
proto 2, so this should still work for protobuf 2.6, etc.
See https://developers.google.com/protocol-buffers/docs/reference/proto2-spec
This change modifies CryptState to use AES_KEY_SIZE_BYTES and
AES_KEY_SIZE_BITS constants instead of using AES_BLOCK_SIZE.
This cleans up the code, making it easier to read and understand.
The key size is a distinct concept from the block size, even though
Mumble only offiiclaly supports OCB-AES128.
This also allows users of custom builds to bump their key size to
256-bit, if they desire. Of course, such builds will not be compatible
with any existing Mumble server, because neither Mumble nor Murmur
currently supports negotiating the crypto mode used for voice packets.
We already log to Windows's debug log, but this is a little more
accessible for regular users and developers alike. (Sometimes, you don't
have DebugView handy...)
