This makes a few modifications to the statusbar text generation:
* Use the canonical U+XXXX representation of unicode characters.
* For control characters, display their alias instead of whitespace.
* Substitute RTL codepoints with U+FFFD so the text paints correctly.
* Only show the glyph's dimensions if it actually exists in the font.
This fixes#7286.
This introduces the UnicodeUtils file, which contains helper functions
related to Unicode. This is in contrast to StringUtils, whose functions
are not directly related to Unicode and are, in theory,
encoding-agnostic.
This hack allows for Boxes that have a background to be painted and a
border to accurately paint their border-radii if needed.
For that the box in with the background is drawn is extended to the
bordered_rect. The border is later drawn over this regardless.
Previously when drawing a Box that had all three, background, border
and a border-radius, there could be some white between the filling and
the border.
The struct BorderRadiusData contains the four radii of the box.
In case the specified borders are too large for the dimensions of the
box, they get scaled down.
This adds a function to draw a circle specified by a center point (
relative to the given Rect) and a radius. The circle arc is only drawn
inside the specified Rect as to allow for circle arc segments.
Technically this was already possible using draw_elliptical_arc(), but
the algorithm is quite involved and lead to wonky arcs when trying to
draw circle arc segments.
This takes care of the 1, 2, 3 and 4 parameter shorthand of the border-
radius identifier.
There are more as well as the ominous '/' character but that is for
another time. The 2 and 3 parameter versions are weird enough already.
I don't think anybody uses anything other than the 1 or 4 parameter
version or even the elliptical stuff.
This was breaking ports linting, which runs the script with the
'showproperty' option. This check is not needed for some other options
as well, so let's do it conditionally.
Some people apparently like to type in full absolute paths into the
filename box of GUI::FilePicker. So let's handle that as you'd expect
by using the full path as the selected path.
Simply by checking whether a built libc.so exists, we should be able to
avoid strange build errors where that's not the case and just tell the
user upfront.
Fixes#7309.
Previously, this code would create a bitmap with the size of the screen
resolution, draw the new wallpaper into it, and then scale it down for
display inside the MonitorWidget.
This was done on every paint event, which made the code quite slow and
allocation-happy.
Instead of this, we now scale down the new wallpaper to a miniature
of the same scale as the little MonitorWidget screen. The miniature is
then used for tiling, etc. The miniature is cached and reused across
paint events if nothing else changes.
An application that allows opening arbitrary files from the filesystem
needs to allow itself to access the filesystem, otherwise there's no
point in supporting the feature. :^)
And the "thread" pledge is needed for background thumbnail generation.
I introduced this bug in e95eb7a51, where it's possible that the
ProcessGroup is created, but we never add it to the list. Make sure we
check that we are in the list before removal. This only broke booting in
self-test mode oddly enough.
Reported-By: Andrew Kaster <andrewdkaster@gmail.com>
Removing the element from the intrusive linked list might not be safe
if doing so requires a lock. Instead this is something the caller
should have done so let's verify instead that we're not on any lists.
In cases with ambiguous captures involving pawns (where multiple pieces
could have made the capture), we were exporting invalid syntax for
the move:
`1. e4 e5 2. Bb5 c6 3. Bxc6 ddxc6`
Move 3 should be `Bxc6 dxc6`, but we were duplicating the d on the pawn
move.
Avoid allocating while holding the g_process_groups_lock spinlock, it's
a pattern that has a negative effect on performance and scalability,
especially given that it is a global lock, reachable by all processes.
Currently in SMP mode we hard code support for up to only 8 processors.
There is no reason for this to be a dynamic allocation that needs to be
guarded by a spinlock. Instead use a Array<T* with inline storage of 8,
allowing each processor to initialize it self in place, avoiding all
the need for locks.