Disable Qt quit-on-last-window behavior on macOS and install an
application-level menu so useful commands remain available after the
last browser window closes.
Reuse shared application actions and menus for Settings, Bookmarks,
History, Help, and global appearance controls. Centralize window-aware
commands such as New Tab, New Window, Open File, Open Location, and
Reopen Recently Closed so the browser window and windowless app menu
use the same behavior. Keep the location editor focused for new blank
windows after the native window has been activated.
Stop forcing RHI for every QWidget on macOS. The web content view is
the only widget that needs Metal, and QRhiWidget already requests that.
Make the web content view a native child before parenting it into the
tab UI so Qt does not propagate its RHI config to the browser window
backing store. This keeps chrome repaints on the normal Cocoa backing
store path instead of copying the full window backing store into a
texture.
Use QRhiWidget for the Qt web content view on macOS and render the
current IOSurface-backed shared image into the widget's Metal render
target. This keeps normal presentation on the GPU instead of painting a
QImage wrapper over the shared bitmap.
Force Qt Widgets' RHI backing store to Metal before QApplication is
created so QRhiWidget can obtain the top-level QRhi even when the native
window is created before the web content widget enters the hierarchy.
Other platforms keep the existing QWidget and QPainter path.
Create new windows with the size of the previously active window, and
maximized if it was maximized. This matches the behaviour of other
browsers, and solves an annoying issue where new windows would always
be tiny.
Application::new_window() now takes a WindowConfiguration struct that
lets you specify the position, size, and maximized-ness of the window.
All previous callers of new_window() now use this instead of modifying
the window state afterwards.
WindowConfiguration is slightly awkwardly broken up into individual x/y
and width/height fields instead of a position and a size, for the sake
of compatibility with HTML::WebViewHints.
We currently create a separate headless-browser application to serve two
purposes:
1. Allow headless browsing to take a screenshot of a page or print its
layout tree / internal text.
2. Run the LibWeb test framework.
This patch migrates (1) to the main Ladybird executable. The --headless
flag enables this mode. This matches the behavior of other browsers, and
means we have one less executable to ship at distribution time.
We want to avoid creating too many AppKit / Qt facilities in headless
mode. So this involves some shuffling of application init to ensure we
don't create them until after we've parsed the command line arguments.
Namely, we avoid creating the NSApp in AppKit and QCoreApplication in
Qt. Doing so also requires that we don't create the application event
loop until we've parsed the command line as well, because the loop we
create depends on whether we're creating those UI facilities.
This adds a WebView::Settings class to own persistent browser settings.
In this first pass, it now owns the new tab page URL and search engine
settings.
For simplicitly, we currently use a JSON format for these settings. They
are stored alongside the cookie database. As of this commit, the saved
JSON will have the form:
{
"newTabPageURL": "about:blank",
"searchEngine": {
"name": "Google"
}
}
(The search engine is an object to allow room for a future patch to
implement custom search engine URLs.)
For Qt, this replaces the management of these particular settings in the
Qt settings UI. We will have an internal browser page to control these
settings instead. In the future, we will want to port all settings to
this new class. We will also want to allow UI-specific settings (such as
whether the hamburger menu is displayed in Qt).
The Qt style hints' color scheme can return ::Unknown, in which case we
still need to fall back to our 'old' method of using the luma component
of the background role color.
For Qt >= 6.5, the system theme can be determined reliably, so no
guesswork is needed. A fallback remains for Qt < 6.5, but it is
hacky and less reliable.
LibWebView now knows how to launch RequestServer and ImageDecoderServer
without help from the UI, so let's move ownership of these services over
to LibWebView for de-duplication.
We currently compile the Qt event loop files multiple times, for every
target which wants to use them. This patch moves these to LibWebView as
a central location to avoid this.
