🏻 - U+1F3FB LIGHT SKIN TONE
🏼 - U+1F3FC MEDIUM-LIGHT SKIN TONE
🏽 - U+1F3FD MEDIUM SKIN TONE
🏾 - U+1F3FE MEDIUM-DARK SKIN TONE
🏿 - U+1F3FF DARK SKIN TONE
This was added in d1de7f7782, but these are not the right code points
(missing U+200D), and we already have a BLACK CAT emoji with the right
code points.
Before, the shading of the Presenter icons was the wrong way round and
the external contrast was not as good as it could be. This has been
rectified and the icons are now light on the left- and dark on the
right-side. Also, they now use the same gray colors as other system
icons, making them sit much more nicely together, and have been
generally improved.
We currently aren't parsing the last line of emoji-serenity.txt because
Core::Stream does not think the last line is readable. We should, of
course, fix Core::Stream. But keeping a trailing newline here is nice
anyways.
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 patch also contains modifications on several classes, functions or
files that are related to the `JPGLoader`.
Renaming include:
- JPGLoader{.h, .cpp}
- JPGImageDecoderPlugin
- JPGLoadingContext
- JPG_DEBUG
- decode_jpg
- FuzzJPGLoader.cpp
- Few string literals or texts
Found using git grep -FIn $'\u00a0'
I just got bit by this type of bug in a different project, and was
wondering whether Serenity has this problem, too. See also:
https://dhwthompson.com/2019/my-favourite-git-commit
Currently when trying to use the right-shift on the pt-br layout
it prints a "?" on key-down on top of applying the shift modifier.
This patch removes the unwanted "?".
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
This patch adds a new gradient tool to pixelpaint that allows us to fill
the canvas with a smooth color gradient outline at the edge of the
filled area.
Let's put test files with the tests themselves, instead of a random user
directory. (But still copy them so they appear in the user directory
for convenience.)
I used this utility to check if the possible TGA images' cases for
different origins (explictly the Y origin) are generating the same
bitmap, as I felt that my eyes are not a good-enough measurement tool
for this kind of task.
This might be useful in the future for testing other implementations so
I rather have this nice utility in our codebase.
