This will help a lot with developing chromes for different UI frameworks
where we can see which helper classes and processes are really using Qt
vs just using it to get at helper data.
As a bonus, remove Qt dependency from WebDriver.
The implementation of this plugin is meant to eventually replace all
current audio plugins in Ladybird. The benefits over the current Qt-
based audio playback plugin in Ladybird are:
- Low latency: With direct access to PulseAudio, we can ask for a
specific latency to output to allow minimal delay when pausing or
seeking a stream.
- Accurate timestamps: The Qt audio playback API does not expose audio
time properly. When we have access directly to PulseAudio APIs, we can
enable their timing interpolation to get an accurate monotonically-
increasing timestamp of the playing audio.
- Resiliency: With more control over how the underlying audio API is
called, we have the power to fix most bugs we might encounter. The
PulseAudio wrappers already avoid some bugs that occur with QAudioSink
when running through WSLg.
Previously, a QTimer was used to start processing of our event queue in
the main Qt event loop. Unfortunately, QTimers are not thread-safe, and
disallow starting of a timer from a different thread than it was
created in.
Instead, use a dummy QObject to post a custom QEvent to the main loop
from whatever thread we like, and process our event queue when it is
received by our dummy object.
Now that all the classes for Ladybird are in the Ladybird namespace, we
don't need them named as Ladybird::FooBarLadybird. For the Qt-specific
classes, we can tack on a Qt at the end for clarity, but FontPlugin and
ImageCodecPlugin no longer have anything to do with Qt.
LibTLS still can't access many parts of the web, so let's hide this
behind a flag (with all the plumbing that entails).
Hopefully this can encourage folks to improve LibTLS's algorithm support
:^).
The Qt relationship was removed in de31a8a4, so let's acknowledge that
and make it clearer to potential non-Qt ports that this file is usable
by them :^).
Now that we no longer use QFont from LibWeb, we can also stop using
QGuiApplication in the WebContent process entirely.
This removes a whole bunch of unnecessary work from the event loop,
and also allows nice things like running headless-browser while
*actually* headless. :^)
We don't need the extra gradle files in our sources, the Qt CMake
integration will generate suitable ones for us.
Make sure that assets is always a folder, so that we can get the proper
layout for the ladybird-assets.tar.gz and CMake doesn't create a gzip
file with the name "assets".
Fix up the AndroidPlatform file and make sure it's linked into all the
applications that need it. Also make sure to copy all the application
shared libraries into the ladybird APK so that when we make them into
proper Services, the libs are already there.
This implementation detail of audio support in ladybird is a QObject
that needs moc'd by the moc tools. Putting it in its own file follows
the pattern we have for all the other QObjects in Ladybird.
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.
The WebContent process behaves a bit awkwardly on macOS. When we launch
the process, we have to create a QGuiApplication to access system fonts.
But on macOS, doing so creates an entry in the Dock, and also causes the
WebContent to be focused. So if you enter cmd+Q without first focusing
the Ladybird GUI, WebContent is closed, while the Ladybird process keeps
running.
Now that the Core::EventLoop is driven by a QEventLoop in Ladybird,
we don't need to patch LibWeb with Web::Platform plugins.
This patch removes EventLoopPluginQt and TimerQt.
Note that we can't just replace the Web::Platform abstractions with
LibCore stuff immediately, since the Web::Platform APIs use
JS::SafeFunction for callbacks.
This patch adds EventLoopImplementationQt which is a full replacement
for the Core::EventLoopImplementationUnix that uses Qt's event loop
as a backend instead.
This means that Core::Timer, Core::Notifier, and Core::Event delivery
are all driven by Qt primitives in the Ladybird UI and WC processes.
- Add Qt::Core, Qt::Gui, LibGfx, LibIPC, and LibJS to the ladybird
target, remove LibGL, LibSoftGPU, and LibWebSocket
- Add LibJS to the WebContent target, remove LibWebView
- Order them properly :^)
Regressed in https://github.com/SerenityOS/serenity/pull/15746.
Fixes#108.
Always call platform_init after there's a QApplication, because in the
installed configuration that's how we find the resources.
Try QCoreApplication::applicationDirPath() after looking in ./WebContent
for the WebContent process. In an installed configuration, ladybird and
WebContent will both be in $PREFIX/bin.
Add install rules for WebContent and its linked libraries, for if they
ever differ from ladybird's.
This patch brings over the WebContent process over from SerenityOS
to Ladybird, along with a new WebContentView widget that renders
web content in a separate process.
There's a lot of jank and FIXME material here, notably I had to re-add
manually pumped Core::EventLoop instances on both sides, in order to get
the IPC protocol running. This introduces a lot of latency and we should
work towards replacing those loops with improved abstractions.
The WebContent process is built separately here (not part of Lagom) and
we provide our own main.cpp for it. Like everything, this can be better
architected, it's just a starting point. :^)
