Previously, one could put '\b' in a keymap, but in non-Terminal
applications, it would just insert a literal '\b' character instead of
behaving like backspace. This patch modifes
`visible_code_point_to_key_code` to include backspace, as well as
renaming it to `code_point_to_key_code` since '\b' is not a visible
character. Additionally, `KeyboardDevice::key_state_changed` has been
rearranged to apply the user's keymap before checking for things like
caps lock.
On account of row and column headers, when a user navigates to
a cell (for example in the spreadsheet application) that is
outside of the view, the cell is not properly aligned and so
is partially cut-off. This fix takes into account the row and
column headers when calculating the Rect to pass to the
scroll_into_view function.
ECMA-402 now supports short-offset, long-offset, short-generic, and
long-generic time zone name formatting. For example, in the en-US locale
the America/Eastern time zone would be formatted as:
short-offset: GMT-5
long-offset: GMT-05:00
short-generic: ET
long-generic: Eastern Time
We currently only support the UTC time zone, however. Therefore, this
very minimal implementation does not consider GMT offset or generic
display names. Instead, the CLDR defines specific strings for UTC.
This property tells CMake that if a library is missing a SONAME field,
the link editor(s) we use will insert the full path to the library into
the binary. This is the behaivor of GNU ld compatible linkers, so let's
avoid that possiblity by telling CMake that it really doesn't want to
let the linker embed the full path to the lib. This is especially
important when cross-compiling things for ports and such, as the full
path to the lib will have absolutely nothing to do with the runtime path
By setting CMAKE_MODULE_PATH in the LLVM initial cache scripts, we can
make the "SerenityOS" CMAKE_SYSTEM_NAME usable in the builds of
compiler-rt, libunwind, libcxxabi and libcxx.
This simplifies some toolchain patches and brings the cross-compiler
patches closer to the Port's patches, and closer to something
upstreamable.
The function `KString::must_create()` can only be enforced
during early boot (that is, when `g_in_early_boot` is true), hence
the use of this function during runtime causes a `VERIFY` to assert,
leading to a Kernel Panic.
We should instead use `TRY()` along with `try_create()` to prevent
this from crashing whenever a USB device is inserted into the system,
and we don't have enough memory to allocate the device's KString.
Spider was only updating the new bounding box area after drawing cards
from the deck - leaving behind a sliver of the old deck.
This was a regression, as the game previously used the old bounding
box, introduced by GH-11153.
Since NVME devices end with a digit that indicates the node index we
cannot simply append a partition index. Instead, there will be a "p"
character as separator, e.g. /dev/nvme0n1p3 for the 3rd partition.
So, if the early device name ends in a digit we need to add this
separater before matching for the partition index.
If the partition index is omitted (as is the default) the root file
system is on a disk without any partition table (e.g. using QEMU).
This enables booting from the correct partition on an NVMe drive by
setting the command line variable root to e.g. root=/dev/nvme0n1p1
Previously, SoundPlayer would read and enqueue samples in the GUI loop
(through a Timer). Apart from general problems with doing audio on the
GUI thread, this is particularly bad as the audio would lag or drop out
when the GUI lags (e.g. window resizes and moves, changing the
visualizer). As Piano does, now SoundPlayer enqueues more audio once the
audio server signals that a buffer has finished playing. The GUI-
dependent decoding is still kept as a "backup" and to start the entire
cycle, but it's not solely depended on. A queue of buffer IDs is used to
keep track of playing buffers and how many there are. The buffer
overhead, i.e. how many buffers "too many" currently exist, is currently
set to its absolute minimum of 2.
Previously, FlacLoader would read the data for each frame into a
separate vector, which are then combined via extend() in the end. This
incurs an avoidable copy per frame. By having the next_frame() function
write into a given Span, there's only one vector allocated per call to
get_more_samples().
This increases performance by at least 100% realtime, as measured by
abench, from about 1200%-1300% to (usually) 1400% on complex test files.
It also needs to be able to take what the spec calls 'empty', which is
an Optional<Value> in this case (*not* an empty JS::Value). The common
use case is updating a completion with another completion, that may also
have an empty [[Value]] slot.
This is a normative change in the Intl spec:
f0f66cf
There are two main changes here:
1. Converting BigInt/Number objects to mathematical values.
2. A change in how ToRawPrecision computes its exponent and significant
digits.
For (1), we do not yet support BigInt number formatting, thus already
have coerced Number objects to a double. When BigInt is supported, the
number passed into these methods will likely still be a Value, thus can
be coereced then.
For (2), our implementation already returns the expected edge-case
results pointed out on the spec PR.
This is a normative change in the Intl spec:
f0f66cf
Our implementation is unaffected by this change. LibUnicode pre-computes
positive, negative, and signless format patterns, so we already format
negative infinity correctly. Also, the CLDR does not contain specific
locale-dependent strings for negative infinity anyways.
- Use umask() to prevent the parent process from tampering with the mode
bits of replacement passwd and shadow files.
- Use fchmod() to set new shadow files to mode 0600.
We should not expect LibC functions to clear `errno` on success,
so if we want to use it for error checking after a call, we need
to clear it before the call.
This means you can now do queries like:
```css
@media (400px <= width < 800px) { }
```
Chromium and Firefox which I tested with both don't support this yet, so
that's cool. :^)
Past me decided that the grammar was overly verbose and I could do it
better myself. Which seemed fine until the spec changed and I didn't
know how to integrate the changes. Lesson learned! :^)
Rather than have a function for every single part of the grammar, I have
written some as lambdas, and combned `<media-condition>` and
`<media-condition-without-or>` into one function. But otherwise it's
close to the spec, with comments listing the part of the grammar being
parsed, so hopefully it will be easier to make future adjustments!
This does not add any new functionality.
Web::CSS::MediaQuery::MediaFeature::Type was getting a bit ridiculous!
Also, this moves the detection of "min-" and "max-" media-features into
the MediaFeature itself, since this is an implementation detail, not
part of the spec.
Having these in here was a hack to support the other hack of making
media-queries use StyleValues. Now they don't do that, so we can remove
these again and keep things hygienic.
Previously, we were using StyleValues for this, which was a bit of a
hack and was brittle, breaking when I modified how custom properties
were parsed. This is better and also lets us limit the kinds of value
that can be used here, to match the spec.
