In order to propagate errors that occur during UI setup, we have to move
all that logic out of widget/window subclass constructors. This is a
first attempt at doing that, for GUI::SettingsWindow.
This is functionally the same as before, as selecting a tab fires Show
and HideEvents. But this way, we don't need to directly access the
TabWidget, which will make using SettingsWindow simpler.
Load the wallpaper in a background action instead of on the main thread.
This reduces the time to first paint, and makes the UI feel more
responsive when clicking on wallpaper thumbnails.
The behavior of the method is changed slightly to return true if it
succesfully "loads" the empty path. This makes the API a little more
consistent, where "true" means "I made changes" and "false" means "I did
not make changes". No call sites currently use the return value, so no
changes are needed to those.
This allows for typing [8] instead of [8, 8, 8, 8] to specify the same
margin on all edges, for example. The constructors follow CSS' style of
specifying margins. The added constructors are:
- Margins(int all): Sets the same margin on all edges.
- Margins(int vertical, int horizontal): Sets the first argument to top
and bottom margins, and the second argument to left and right margins.
- Margins(int top, int vertical, int bottom): Sets the first argument to
the top margin, the second argument to the left and right margins,
and the third argument to the bottom margin.
Previously the argument order for Margins was (left, top, right,
bottom). To make it more familiar and closer to how CSS does it, the
argument order is now (top, right, bottom, left).
This enables changing monitor settings for each monitor individually.
In the event that changing a resolution causes screens to overlap we
now try to disperse the screens, although the algorithm currently
implemented may result in some rather unexpected layouts in certain
cases. We can still improve this logic, and eventually we're going to
have a widget where the screens can be arranged as desired.
The FontSettings widget now uses background_role instead of
background_color to ensure that it displays properly independently of
the active system theme.
This sets the stage so that DisplaySettings can configure the screen
layout and set various screen resolutions in one go. It also allows
for an easy "atomic" revert of the previous settings.
This allows WindowServer to use multiple framebuffer devices and
compose the desktop with any arbitrary layout. Currently, it is assumed
that it is configured contiguous and non-overlapping, but this should
eventually be enforced.
To make rendering efficient, each window now also tracks on which
screens it needs to be rendered. This way we don't have to iterate all
the windows for each screen but instead use the same rendering loop and
then only render to the screen (or screens) that the window actually
uses.
Previously, AK::Function would accept _any_ callable type, and try to
call it when called, first with the given set of arguments, then with
zero arguments, and if all of those failed, it would simply not call the
function and **return a value-constructed Out type**.
This lead to many, many, many hard to debug situations when someone
forgot a `const` in their lambda argument types, and many cases of
people taking zero arguments in their lambdas to ignore them.
This commit reworks the Function interface to not include any such
surprising behaviour, if your function instance is not callable with
the declared argument set of the Function, it can simply not be
assigned to that Function instance, end of story.
Pull out the Label updating code into its own function.
Ideally, we should probably transform this code to use its own widget
rather than doing this all in-line.
I.e., having a `FontSettingWidget` that that ties the FontPicker, Label
and Button into its own little widget, so that we can stay extendible in
the main widget and reduce duplication some more!
Previously, the font was applied to the Labels but the name wasn't
updated on initial startup.
This meant that the Label's content was only correct in the default
state but not if the user changed the defaults.
