This is an initial implementation of the accname standard. There is
still some of the algorithm left unimplemented that we will need
to implement in the future. However, as is, this implementation is
sufficient for basic pages.
Using the walk_device_tree helper, we can walk the device tree from the
beginning looking for a specific property node. It's still missing the
ability to get property lists, string lists, and property-specific data.
This subdirectory is meant to hold all constant data related to the
kernel. This means that this data is never meant to updated and is
relevant from system boot to system shutdown.
Move the inodes of "load_base", "cmdline" and "system_mode" to that
directory. All nodes under this new subdirectory are generated during
boot, and therefore don't require calling kmalloc each time we need to
read them. Locking is also not necessary, because these nodes and their
data are completely static once being generated.
👂 - U+1F442 Ear
Improve + bring colors in line with other body part emojis
👃 - U+1F443 Nose
Improve + bring colors in line with other body part emojis
👅 - U+1F445 Tongue
🤌 - U+1F90C Pinched Fingers
🤘 - U+1F918 Sign of the Horns
The test verifies that loading an icc file and serializing it
again produces exactly the same output as the input. That's not
always the case, but often. It requires the input file either
not having any padding or using null bytes as padding, it
requires the input file putting tag data in the order the
tag data is referenced in in the tag table, and it requires the
input file only using known tag types (which at the moment
means it only works for v4 profiles, but that part will change
in the future).
The new file p3-v4.icc was extracted from a jpeg taken by an
iPhone Mini.
With this, common v4 profiles, such as embedded into jpgs by iPhones
(when configured to write jpegs) or Pixel phones, are identical to
the input when reexported :^)
Restart markers are supposed to be applied every restart interval.
However, in these loops macroblocks are counted taking the luma sampling
factor into consideration. Meaning that we need to correct this factor
when testing if we should reset the DC.
Also, the decoder was discarding the first byte of every scan with a set
restart interval, as `0 % n == 0` is always true.
This commit allows the text tool's internal TextEditor component to
handle keyboard shortcuts that would normally be handled by menu
actions.
The shortcuts that can now be used are: cut, copy, paste, undo, redo
and select all.
Previously, we only saved the REPL history when the interpreter was
shutdown with a signal. This change ensures that we save the history
when a user uses `exit()`.
This is considered somewhat an abstraction layer violation, because we
should always let userspace to decide on the root filesystem mount flags
because it allows the user to configure the mount table to preferences
that they desire.
Now that SystemServer is modified to re-mount the root mount with the
desired flags, we can just mount the root filesystem without assuming
special flags.
This creates a cached bitmap for each unique screen resolution, which
allows us to share it between displays with the same resolution. If
the resolution is the same as the wallpaper, we can just use the
wallpaper as-is.
When viewing a deeply nested path, there may be very little of the
PathBreadcrumbbar itself visible to double-click on. This solves that
by allowing double-clicks on its segment buttons to behave the same.
(With the caveat that it first selects the double-clicked segment.)
In order to make this work, `on_double_click` now takes the modifiers
instead of the MouseEvent. In this case we don't use it so that's fine,
but maybe we should make all mouse callbacks consistently take the
MouseEvent& as a parameter.
This Widget wraps both a Breadcrumbbar and a TextBox for editing the
path manually, based heavily on the existing code in FileManager.
Breadcrumbbar itself requires outside code to micro-manage what it does.
This class provides a simpler interface for it: Users don't have to
worry about segments, they just give/receive a string for the current
path.
The check of ensuring we are not trying to read beyond the end of the
inode data buffer is already there, it's just that we need to disallow
further reading if the read offset equals to the inode data size.
Apparently we lacked this important check from the beginning of this
piece of code. This check is crucial to ensure we only give back data
being related to the FATInode data buffer and nothing beyond it.
This stops us needing a lot of ugly `FlyString { ... }` wrappers. THis
is the behavior that `DeprecatedFlyString(DeprecatedString)` has so it
should be fine.
I'm not sure why this isn't caught on other people's setups or CI, but
when building on NixOS it fails with:
error: comparison of integer expressions of different signedness:
‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Werror=sign-compare]
Otherwise Qt would not find the wayland plugin it is instructed to use
via QT_QPA_PLATFORM, and would fall back to the second option, xcb,
which looks rather sad in a modern Wayland environment :^)
This feels like something that should be addressed upstream in nixpkgs
eventually.
