This is done as a separate commit to retain Git change file history association. (Git does not store renames. It assumes renames according to content similarity.)
The cross-document reference apparently worked on readthedocs (our previous docs), but does not work on GitHub.
The cross-document figure reference is replaced with a file reference.
Sinks:
- OutputDebugString() (for debugger on Windows)
- Standard output stream (stdout)
- File
- Developer console (Qt widget)
Improvements compared to our old logging system based on Qt:
- Duplicate messages are skipped if less than 5 seconds have passed. When that happens, an informative message is printed.
- The previous format/pattern is retained, but the log level (e.g. "<W>") is colored based on the severity.
- The log is now written to a file on all platforms, not only Windows and macOS.
- When the log file's size reaches 5 MiB, the sink renames it and creates a new one. Up to 4 files are kept:
Console.txt -> Console.1.txt
Console.1.txt -> Console.2.txt
Console.2.txt -> Console.3.txt
Console.3.txt -> <delete>
- We can eventually create multiple loggers, ideally one for each facility (Audio, ServerHandler, etc.).
That would allow us to quickly filter log messages and know right away which subsystem is responsible for them.
- Modern C++ string formatting. This of course only applies to the new functions such as log::debug(), not qDebug().
Only one "feature" is not reimplemented: showing a dialog in case of a fatal error, right before exiting the program.
However, that only worked on Windows and macOS using their native API, to avoid depending on a Qt event loop.
Mumble can be compiled with several system libraries, so add their
development library to the list of Build-Depends.
In order to actually compile with them, you need to specify the
configuration options as described in cmake_options.md.
Those are for the newly added B-Ds:
1) -Dbundled-gsl=OFF
2) -Dbundled-speex=OFF
3) -Dbundled-json=OFF
Closes: #6644
Since Debian Bookworm the pkg-config package is a transitional package
to pkgconf, so update the build dependency install instructions to point
to its target.
In PR 6643 I accidentally updated the instructions for Ubuntu instead of
for Debian, so now actually update the instructions for Debian as well.
FTR: In Ubuntu Noble (2024.04) it's also a transitional package.
Link: https://github.com/mumble-voip/mumble/pull/6643
Since Debian Bookworm the pkg-config package is a transitional package
to pkgconf, so update the build dependency install instructions to point
to its target.
In a folder, GitHub shows a README by default, below the file list.
Combining the index.rst and introduction.rst, with text fixups, will serve as an appropriate landing page/doc.
Dropping the resources for Sphinx documentation generation drops support for generating this documentation into various formats (see make file; html, epub, and other less useful ones).
This network protocol documentation is the odd one out compared to our other documentation. The only one with this system.
Diverse tech has a maintenance cost, and the previous distance to our code made more likely to be missed for updates and discovery.
Handling only the network protocol documentation in this way feels disconnected/diverging.
Although readers may use the docs to implement clients and servers against only the docs, the question is whether the technology and maintenance additions are worth it.
Having simple structured text documentation files should serve us well enough.
It does for other developer documentation / documentation for developers.
We have documentation in the mumble-protocol repository and generated website.
The doc file in this repository serves as a simple reference pointing to those.
See also [mumble-www #59](https://github.com/mumble-voip/mumble-www/issues/59)
Due to RNNoise being unmaintained and the library's code being in very poor shape, this commit excludes the RNNoise feature from Mumble by default and discourages its use.
The library contains Opus and CELT symbols (probably due to copy&paste of code) that can end up being called from Opus instead of its own versions of these functions. This can lead to completely unforeseen behavior, including crashes.
An example of this is as of writing this, enabling RNNoise on macOS leads to a crash of Mumble pretty much as soon as it starts up with an "invalid instruction" error. The reason being that part of RNNoise's implementation of one of Opus's symbols contains a code path that produces an invalid instruction in optimized builds (and a segfault in debug builds) and this code path is taken when Opus (wrongly) uses this function instead of its own.
Fixes#6041
Due to RNNoise being unmaintained and the library's code being in very
poor shape, this commit excludes the RNNoise feature from Mumble by
default and discourages its use.
The library contains Opus and CELT symbols (probably due to copy&paste
of code) that can end up being called from Opus instead of its own
versions of these functions. This can lead to completely unforeseen
behavior, including crashes.
An example of this is as of writing this, enabling RNNoise on macOS
leads to a crash of Mumble pretty much as soon as it starts up with an
"invalid instruction" error. The reason being that part of RNNoise's
implementation of one of Opus's symbols contains a code path that
produces an invalid instruction in optimized builds (and a segfault in
debug builds) and this code path is taken when Opus (wrongly) uses this
function instead of its own.
Fixes#6041
Having different include files that are needed (and which are inter-dependent) to create your own plugin, makes things harder than it needs to be.
Therefore, all plugin header files (those for the "new" (1.4) plugin framework anyway) have been combined into one header file. Thus, developers now only have to download a single file and include that instead of having to figure out what files to download and what to include where.
Taking the chance, the version number has been removed from the header file's name. This allows one to track changes made to the API via git (which is not quite as easy if you create a new file every time you make a change).
Having different include files that are needed (and which are
inter-dependent) to create your own plugin, makes things harder than it
needs to be.
Therefore, all plugin header files (those for the "new" (1.4) plugin
framework anyway) have been combined into one header file. Thus,
developers now only have to download a single file and include that
instead of having to figure out what files to download and what to
include where.
Taking the chance, the version number has been removed from the header
file's name. This allows one to track changes made to the API via git
(which is not quite as easy if you create a new file every time you make
a change).
