The Serenity chrome is the only chrome thus far that sends all input key
and mouse events to WebContent, including shortcut activations. This is
necessary for all chromes - we must give web pages a chance to intercept
input events before handling them ourselves.
To make this easier for other chromes, this patch moves Serenity's input
event handling to LibWebView. To do so, we add the Web::InputEvent type,
which models the event data we need within LibWeb. Chromes will then be
responsible for converting between this type and their native events.
This class lives in LibWeb (rather than LibWebView) because the plan is
to use it wholesale throughout the Page's event handler and across IPC.
Right now, we still send the individual fields of the event over IPC,
but it will be an easy refactor to send the event itself. We just can't
do this until all chromes have been ported to this event queueing.
Also note that we now only handle key input events back in the chrome.
WebContent handles all mouse events that it possibly can. If it was not
able to handle a mouse event, there's nothing for the chrome to do (i.e.
there is no clicking, scrolling, etc. the chrome is able to do if the
WebContent couldn't).
It aligns better with the Filesystem Heirarchy Standard[1] to put our
program-specific helper programs that are not intended to be executed by
the user of the application in $prefix/libexec or in whatever the
packager sets as the CMake equivalent. Namely, on Debian systems this
should be /usr/lib/Ladybird or similar.
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#usrlibexec
We currently bundle AK with LibCore on Lagom. This means that to use AK,
all libraries must also depend on LibCore. This will create circular
dependencies when we create LibURL, as LibURL will depend on LibUnicode,
which will depend on LibCore, which will depend on LibURL.
With this, it's possible to build Ladybird without having Qt installed.
(Previously, the build required `moc` to exist.)
In fact, it's possible to build Ladybird without anything off `brew`
as long as you have `ninja` and `gn` (both of which don't have any
dependencies themselves and are easy to build).
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.
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
:^).
Re-organize our helper files here a bit, to make a clearer distinction
between Qt-specific helpers and generic non-serenity helpers.
A future commit will move Lagom specific code from LibSQL to ladybird
as well, so that we can see about future generic apis for spawning
helper procesess.
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 :^).
This allows opening the ladybird.app app bundle on macOS, using Xcode
tools like Instruments on the applications in the app bundle, and even
installing the app bundle into /Applications :^)
