We were using the available space in place of the stretch-fit size.
This was an oversight, and this patch fixes that. It's very possible
that this will uncover broken behavior elsewhere.
This property tells us how to lay out multi-line flex containers.
I implemented all modes except `space-between` and `space-around`.
Those are left as FIXMEs.
This ensures that we create a line box for content:"", which would
otherwise get pruned by the empty line cleanup in IFC.
The empty line box is important in this case, since it gives us a
reference point for measuring the automatic height of the IFC's
containing block. By having an empty line, we can now correctly measure
the impact of vertical margins on a generated box with content:""
and allow them to contribute to the block height.
When checking if a line box fragment "isn't just dumb inline content",
we were checking "is replaced or inline-block". What we really need to
be checking is "is replaced or inline-outside-but-not-flow-inside".
So now we check that.
This fixes an issue where inline-flex boxes were given incorrect extra
height due to being treated as regular text for purposes of line height
calculation.
Percentage heights are now considered definite when their containing
block has a definite height. This makes profile pictures have geometry
on Twitter. (We still don't load the images themselves though.)
The selected region in HexEditor is indicated by rendering a different
background color for the selected bytes.
Previously this background was rendered so that the background
rectangles were not contigous between different rows. This caused a high
contrast pattern that interfered with the readability of the hexadecimal
digits.
Now the background is rendered as a single contiguous block.
8-bit PCM samples are unsigned, at least in WAV, so after rescaling them
to the correct range we also need to center them around 0. This fix
should make 8-bit WAVs have the correct volume of double of what it was
before, and also future-proof for all other unsigned PCM sample formats
we may encounter.
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
Commit #3197c17 introduced a session based clipboard portal.
This made pixel-paint fail to launch, because it had an unveil that
used the old path to the clipboard. This commit fixes that and now
unveils the new session based clipboard portal.
This was being used as a default version argument in a couple of APIs,
so those need to change signature and the caller always needs to provide
a version.
This change implements a flood fill algorithm for the Bitmap class. This
will be leveraged by various Tools in PixelPaint. Moving the code into
Bitmap reduces the duplication of the algorithm throughout the
PixelPaint Tools (currently Bucket Tool and Wand Select).
The flood fill function requires you to pass in a threshold value (0 -
100) as well as a lambda for what to do when a pixel gets reached. The
lambda is provided an IntPoint representing the coordinates of the pixel
that was just reached.
The genericized lambda approach allows for a variety of things to be
done as the flood algorithm progresses. For example, the Bucket Tool
will paint each pixel that gets reached with the fill_color. The Wand
Select tool wont actually alter the bitmap itself, instead it uses the
reached pixels to alter a selection mask.
Even though this almost certainly wouldn't run properly even if we had
a working kernel for AARCH64 this at least lets us build all the
userland binaries.
The clipboard service hasn't been ported to user-based portals with
others services as it is needed at `GUI::Application` creation and thus
before the first login, as the `LoginServer` needs one.
This problem as been solved thanks to session-based portals, a clipboard
portal is now created at boot for the "login" session and another for
each "user" session.
With a user-based portal, the "login" portal would have needed to be
created for the `root` user, exposing us to security issues. It now, can
be owned by the `window` user.
