This patch fixes `nix develop` commands not using proper paths, uses
the serenity root directory as an assumption for all commands and
adds variants of nix commands to use a custom entry point, for example
a shell.
If PulseAudio is available, the Qt6 audio plugin will never be used. So
let's remove it from the build.
Note that on macOS, the Qt6 audio plugin will be used if the Qt chrome
is enabled. Otherwise, Audio Unit will be used for the AppKit chrome.
Add another dev shell to `Toolchain/flake.nix` called `ladybird.nix`
that pulls in the dependencies for building Ladybird.
Also update the documentation to mention building with a flake.
The documentation for building Ladybird gives a list of packages to
install under openSUSE, but is missing the Qt6 Multimedia development
package, qt6-multimedia-devel.
Include it.
The build instructions include build-essential,
which installs gcc and g++.
However, build-essential's currently stable version (v12.9) depends on
a version of g++ < 12, thus, Ladybird doesn't build.
Doing this removes the qt6-svg dependency and allows our rasterizer to
be used for these little icons (and happens to be a fair bit smaller
than the old SVGs).
This creates (and installs upon WebContent startup) a platform plugin to
play audio data.
On Serenity, we use AudioServer to play audio over IPC. Unfortunately,
AudioServer is currently coupled with Serenity's audio devices, and thus
cannot be used in Ladybird on Lagom. Instead, we use a Qt audio device
to play the audio, which requires the Qt multimedia package.
While we use Qt to play the audio, note that we can still use LibAudio
to decode the audio data and retrieve samples - we simply send Qt the
raw PCM signals.
There have been multiple reports of Xcode 14.0 (based on upstream LLVM
14) segfaulting when compiling `LibCore/Process.cpp`. Let's require
Xcode 14.3, which is a known good version based on LLVM 15.
Note that Xcode 14.3 requires macOS Ventura, so users of Monterey or
older are expected to get Homebrew Clang instead.
Homebrew Clang 13 also suffers from the same crash. Although I have not
tested on Linux, the backtrace points to the middle-end, so x86_64 is
also likely to be affected. LLVM 14 was released 14 months ago, so it's
not an unreasonable requirement.
