This patch implements the full "old model" height algorithm from the
CSS Positioned Layout spec. I went with the old model since we don't
yet have the machinery required to implement the new model.
Also, the width calculations already follow the old model, so this
is symmetric with that. Eventually we should of course implement the new
positioned layout model.
If the entire string you want to right-trim consists of characters you
want to remove, we previously would incorrectly leave the first
character there.
For example: `trim("aaaaa", "a")` would return "a" instead of "".
We can't use `i >= 0` in the loop since that would fail to detect
underflow, so instead we keep `i` in the range `size .. 1` and then
subtract 1 from it when reading the character.
Added some trim() tests while I was at it. (And to confirm that this was
the issue.)
The hot-spots for resizing a window by dragging its corner are now
limited to a small area around the actual corner instead of an area with
1/3rd the length or width of the window.
The hot-spots to resize a window while holding a modifier key and the
right mouse button are unchanged.
This fixes issue #14429. The editor actions were not given a parent as
scope so defaulted to global. Because HackStudio can have multiple
editors and even multiple editor tab widgets, I chose the
VerticalSplitter that all editor tab widgets get added to as the parent.
With a Widget set as the parent, the action gets WidgetLocal scope and
allows the embedded terminals to receive shortcuts.
Thanks to Andreas for doing a quick look at this and pointing in the
right direction during an Office Hours stream :)
Neither are we changing any of our documentation files, nor do we need
any of the documentation that is likely being built.
With macOS potentially removing makeinfo from the default Xcode lineup,
SerenityOS not being able to install it at all currently due to a lack
of perl, and it otherwise just being a dependency that has to be
installed to make the build system happy, lets just stub it out.
Now that intrinsic heights (correctly) depend on the amount of available
width, we can't just cache the first calculated min-content and
max-content heights and reuse it without thinking.
Instead, we have to cache three pairs:
- min-content & max-content height with definite available width
- min-content & max-content height with min-content available width
- min-content & max-content height with max-content available width
There might be some more elegant way of solving this, but basically this
makes the cache work correctly when someone's containing block is being
sized under a width constraint.
We were incorrectly resolving them against the available width, which
may or may not be the same as the containing block width.
The specification for these properties says that percentages resolve
against the containing block width, so that's what we should do.
When calculating the fit-content width or height for a flex item, we
need to use the available space *outside* the item, not the available
space *inside*.
We now know exactly how to calculate the min-content cross size for
multi-line flex containers, which is great. The other three intrinsic
constraints still fall back to the old ad-hoc code path.
5630e7b064
The main benefit of this is respecting the iframe frameborder
attribute, as frameborder="0" is a pretty common way of removing
the default <iframe> border.
For example, it's on all YouTube embeds by default and on some
ReCAPTCHA embeds.
This was only used for asking the stack if it is the one we are moving
cards from. We now have a better way to do that, by comparing against
`CardGame::moving_cards_source_stack()`, which doesn't require manually
telling a stack that it is/isn't focused.
Previously, dropping a card that overlapped multiple stacks that could
accept it, would always choose the stack that came first in the stacks
list, usually the leftmost one. This would feel very odd if the card
was only slightly overlapping the left stack, and 90% over the right
one. So now, we keep looking for closer stacks even once we've found a
valid one.
There may be an option that feels even better, based on the position of
the card being dragged and the card on top of the stack we're dropping
onto, but this already fixes the issue and feels very nice. :^)
Solitaire and Spider have almost identical code for dragging cards from
one stack to another, so it makes sense to move that here. But using
the term "moving" for them, instead of "focused" which (to me at least)
was not clear what it meant.
As part of this, made a const overload for `Card::rect()`. We need the
non-const one too as it's used for modifying the position of a card
that's being dragged. I plan on changing that soon but we'll see.
And while I'm at it, clarify the name of `associated_stack` to
`covered_stack`. It's used in exactly one way, so we can make the code
clearer by giving it a less generic name.
`create_standard_deck()` is the usual 52-card deck, but more custom
setups (such as Spider's multiples-of-one-suit) can be created by
passing suit counts to `create_deck()`.
This file implements the POSIX APIs from <regex.h>, and is not suitable
for inclusion in a Lagom build. If we do include it, it will override
the host's regex functions and wreak havoc if it's resolved before the
host's implementation.
By passing AF_UNSPEC to getaddrinfo, we're telling the system's
implementation that we are ok getting either (or both) IPv4 and IPv6
addresses in our result. On my Ubuntu 22.04 system, the first addrinfo
returned for "www.google.com" holds an IPv6 address, which when
interpreted as an IPv4 sockaddr_in gives an address of 0.0.0.0.
This fixes TestTLSHandshake in Lagom locally.
This test file had #ifdef macros at the top that caused none of the
content to be compiled unless a developer manually wanted to run the
specific benchmarks within. As such, it has become stale. Remove it for
now, if someone wants to restore it in an always-runnable state, we can
restore the specific tests it's trying to benchmark.
This filter mimics the functionality from Photoshop and other image
editors, allowing you to adjust the hue, saturation, and lightness of
an image. I always found this a very handy feature :^)
