We don't need it. A recent change to the ubuntu-20.04 image has made it
the default, causing builds to fail - we're installing and want to use
clang-12 anyway, so let's just get rid of the other installed versions.
If a line was larger than 1024 bytes or the file ended without a
newline character, can_read_line would return false.
IODevice::can_read_line() now reads until a newline is found or
EOF is reached.
fixes#5907
When reading from stdin, grep discards the last character,
even if that character is not \n.
This commit changes grep to no longer discard the last character from
a line.
This unifies how 3DFileViewer handles the initial file when starting
the application and when opening files later on via the menu.
Errors are shown both for the initial load as well as when loading
files later on. An error during file load no longer clears the
existing model.
It also adds support for specifying the filename as a command-line
argument.
The opened file's name is shown in the titlebar.
The HTML and Markdown preview modes both use an OutOfProcessWebView to
render the preview pane, and we were instantiating this view from GML.
This caused us to always spawn a WebContent process alongside every
TextEditor instance.
Fix this by deferring the OOPWV construction until we actually need it.
This makes launching TextEditor on a text file quite a bit faster. :^)
Instead of doing a full IPC round-trip for the client and server to
greet each other upon connecting, the server now automatically sends
a "fast_greet" message when a client connects.
The client simply waits for that message to arrive before proceeding.
(Waiting is necessary since LibGUI relies on the palette information
included in the greeting.)
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.
