This patch does three things:
- Font::has_color_bitmaps() (true if CBLC and CBDT are present)
- Glyph now knows when its bitmap comes from a color bitmap font
- Painter draws color bitmap glyphs with the appropriate scaling etc
This moves color to be the first value resolved, this ensures that
calls to .to_color() on style values for other properties will always
be able to resolve the current color.
This change fixes the `background-color: currentColor` example in
colors.html.
This changes the parameters parsed from a WebDriver HTTP request to
String for transferring over IPC. Conveniently, most locations these
were ultimately passed to only need a StringView.
This will allow easily surrounding operations that may fail due to OOM
with TRY. Note that we now also have to define a "normal" constructor
for WebDriver::Error in order to add the AK::Error constructor.
Past a few hundred matches, the search is no longer useful, and takes an
excessive amount of time to recalculate the column widths by measuring
thousands of pieces of text. 250 seems like a reasonable arbitrary
limit, and keeps things nice and snappy. :^)
From the WebIDL grammar:
(https://webidl.spec.whatwg.org/#prod-Argument)
Argument ::
ExtendedAttributeList ArgumentRest
ArgumentRest ::
optional TypeWithExtendedAttributes ArgumentName Default
TypeWithExtendedAttributes ::
ExtendedAttributeList Type
One IDL file has been updated to match the spec literally, as it can now
be parsed properly.
`Core::Directory::for_each_entry()` takes a callback which is passed the
DirectoryEntry and the parent Directory. It returns any error from
creating the iterator, iterating the entries, or returned from the
callback.
As a simple example, this:
```c++
Core::DirIterator piece_set_iterator { "/res/icons/chess/sets/",
Core::DirIterator::SkipParentAndBaseDir };
while (piece_set_iterator.has_next())
m_piece_sets.append(piece_set_iterator.next_path());
```
becomes this:
```c++
TRY(Core::Directory::for_each_entry("/res/icons/chess/sets/"sv,
Core::DirIterator::SkipParentAndBaseDir,
[&](auto const& entry, auto&) -> ErrorOr<IterationDecision> {
TRY(m_piece_sets.try_append(entry.name));
return IterationDecision::Continue;
}));
```
`Directory::path()` returning `ErrorOr` makes it awkward to use, and all
current users create a Directory with a path. If we find we need
pathless directories later, we can come up with a clever solution
then. :^)
This also removes DirIterator::error_string(), since the same strerror()
string will be included when you print the Error itself. Except in `ls`
which is still using fprintf() for now.
Our `find` utility makes use of the `dirent::d_type` field for filtering
results, which `Core::DirIterator` didn't expose. So, now it does. :^)
We now store the name and type of the entry as the "next" value instead
of just the name. The type is exposed as a `DirectoryEntry::Type`
instead of a `DT_FOO` constant, so that we're not tied to posixy
systems, and because proper enums are nice. :^)
This widget originally used text, but at the time we did not support
painting multi-code point emoji as text at all. So it was changed to
paint emoji with their bitmaps in commit 8190120f95.
Now that we can paint text with multi-code point emoji, revert this
widget to use text again. This has the added benefit that the dialog has
a what-you-see-is-what-you-get effect; any emoji with text presentation
in the font (e.g. U+00A9 Copyright) will be displayed as such in the
dialog, which is how the text would be painted when selected anyways.
Note that to accommodate some emoji sizes, this also had to bump the
button sizes a bit, otherwise they would be displayed with an ellipsis.
The EmojiInputDialog, for example, will want its toolbar buttons to have
a tooltip which differs from its text. If no tooltip override has been
provided, we fall back to the button text still.
This was preventing some unqualified emoji sequences from rendering
properly, such as the custom SerenityOS flag. We rendered the flag
correctly when given the fully qualified sequence:
U+1F3F3 U+FEOF U+200D U+1F41E
But were not detecting the unqualified sequence as an emoji when also
filtering for emoji-presentation sequences:
U+1F3F3 U+200D U+1F41E
The values aren't 100% self-consistent, but it probably doesn't make
a difference for u8 color data. Good enough for now. See all the links
on #17714 for some more background.
This creates folding regions for blocks defined by the following:
- if/elseif/else/endif
- foreach/endforeach
- while/endwhile
- macro/endmacro
- function/endfunction
Since there is no guarantee that each keyword will have a matching
partner, we do our best by looking for the most recent possible start
token matching the current end token. If we find one, we link to it and
drop all the other start-tokens that happened in between. For example,
we would define a folding region for this invalid file like so:
[-] if(TRUE)
│ while()
└─ endif()
This sorts the array of generated emoji data by code point (first by
code point length, then by code point value). This lets us use a binary
search to find emoji data, rather than the current linear search.
In a profile of scrolling around /home/anon/Documents/emoji.txt, this
reduces the runtime of Gfx::Emoji::emoji_for_code_points from 69.03% to
28.42%. Within that, Unicode::find_emoji_for_code_points reduces from
28.42% to just 1.95%.
