Holding shift while using the polygonal select tool now constrains the
line angle in 22.5 degree increments. This matches the behavior of the
line tool.
When calling ioctl on a socket with SIOCGIFHWADDR, return the correct
physical interface type. This value was previously hardcoded to
ARPHRD_ETHER (Ethernet), and now can also return ARPHRD_LOOPBACK for the
loopback adapter.
We currently paint the 3 previewed cards using ImageWidget. This works
fine, but in order to preview a card hovering over a valid target card,
it will be easier to use the already-existing CardGame paint logic. So
this patch changes GamesSettings to display the preview as-is using a
CardGame.
Before we used the value of days which may also contain a fraction.
The algorithm expects it to be an integer.
This was addressed upstream in: tc39/proposal-temporal@02379da
This starts moving code equally shared between the OOPWV and Ladybird
WebContentView implementations to WebView::ViewImplementation, beginning
with the client state.
On many keyboards, Ctrl++ is actually Ctrl+Shift+=, and Ctrl+= makes
more sense as it's symmetric with Ctrl+-.
Both Firefox and Chrome already support this alternate shortcut,
so let's be nice and support it in Ladybird as well. :^)
Before this patch, we were expressing the current selection as a range
between two points in the layout tree. This was a made-up concept I
called LayoutRange (2x LayoutPosition) and as it turns out, we don't
actually need it!
Instead, we can just use the Selection API from the Selection API spec.
This API expresses selection in terms of the DOM, and we already had
many of the building blocks implemented.
To ensure that selections get visually updated when the underlying Range
of an active Selection is programmatically manipulated, Range now has
an "associated Selection". If a range is updated while associated with
a selection, we recompute layout tree selection states and repaint the
page to make it user-visible.
Instead of sifting through the layout tree to extract the selected text,
look at the DOM selection instead.
Note that we can't just stringify the DOM Range, as that would include
non-visible things (like the content of <style> elements, etc.) so we
run it through an ad-hoc variant of the range stringification algorithm.
This can probably be factored better, but it's a start. :^)
If we failed to decode a sample we'd presumably want to tell the user,
and we definitely don't want to just go into another round of decoding
somewhere in the middle of a broken sample.
Especially if buffered streams are involved, not filling the span
completely can also mean that we just ran out of filled buffer space and
we need to refill it on the beginning of the next read call.
