Previously the "Theme" tab in DisplaySettings would only reflect the
current theme on startup and get out of sync when a theme would get
selected using the taskbar menu.
Previously we would assume that the theme would only change through the
taskbar menu. As the theme can also be changed in DisplaySettings, the
selected theme in the taskbar menu would get out of sync.
With this patch the menu will get updated every time the theme changes
and the menu is not shown.
In a previous commit I moved everything into the new subdirectories in
FileSystem/SysFS directory without trying to actually make changes in
the code itself too much. Now it's time to split the code to make it
more readable and understandable, hence this change occurs now.
This is necessary for the next commit in the patch, otherwise this can't
be compiled. It seems like this was a hidden issue that is discovered
now only by changing includes in a mass-scale.
* Always return 0 if `WNOHANG` is specified and no waitable child is
found, even if `wstatus` is null.
* Do not return 0 if the child is continued. Treat it the same way as
all the other states.
Refer to the RETURN VALUE section of the POSIX spec:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html
Before, when holding at a location in the gutter until the scrubber
reached that location, the gutter would stay tinted, even after the
target was reached, and the scrubber didn't move any more; only
stopping when the pointer was moved.
While `core.autocrlf=false` should be the default, there will certainly
be users that have changed the default setting in their global
configuration.
Ensure that the setting is disabled to avoid accidentally mangling or
not applying our patches.
Previously, this was slightly off and not doing what the spec comment
above asked for. This led to really small values for x_step and
y_step, making the `backgrounds.html' example use crazy amounts of
CPU whist painting.
From the spec:
> This property previously accepted the values optimizeSpeed and
optimizeQuality. These are now deprecated; a user agent must accept
them as valid values but must treat them as having the same behavior
as pixelated and smooth respectively, and authors must not use them.
- https://www.w3.org/TR/css-images-3/#the-image-rendering
Previously keymap did switching of the selected keymap twice when the
command was executed. First set it to the first keymap on the list and
later, if present, to the chosen one.
Currently the switching to the first keymap on the list is done only
when the selection is not present or it's not on the list of keymaps.
It's probably not in 1:1 as spec says, as it wants us to first upscale
the image to the nearest integer and then downscale it bilinearly.
But this mode still falls into the general description of the value:
> The image is scaled in a way that preserves the pixelated nature of
> the original as much as possible, but allows minor smoothing instead
> of awkward distortion when necessary.
Also, this way we don't have to allocate the memory just for the integer
scale. :^) :^)
If you wanted to upscale an image, you had two options:
- use Nearest Neighbor: it's probably a good choice. The image stays
sharp.. unless you aren't using integer scales.
- use Bilinear blending, but this on the other hand, doesn't handle
upscaling well. It just blurs everything.
But what if we could take the best of both of them and make the image
sharp on integers and just blur it a little when needed?
Well, there's Smooth Pixels!
This mode is similar to the Bilinear Blend, with the main difference
is that the blend ratio is multiplied by the current scale, so the blur
on corners can be only 1px wide.
From my testing this mode doesn't handles downscaling as good as the
Bilinear blending though.
This is a helper class for clipping the corners off a element.
This works in a similar way to how (outline) borders are painted.
The steps are:
1. A small bitmap that fits only the corners is allocated
2. The corners are painted into the bitmap
3. The existing pixels (where the corners will be painted)
are copied using the (inverse) corner bitmap as a mask
(done before the element is painted)
4. The element is painted
5. The areas outside the corner radii are restored
Like with the borders, this only requires allocation on the first
paint.
