The goal of these more recent additions to the Dockerfile is to provide
a working copy of SerenityOS with the toolchain prebuilt. To me, these
additions feel misplaced:
- The toolchain is built assuming the i686 architecture, which may not
be what you want.
- You get a shallow clone of the project limiting you in your abilities
to navigate through the project's history or bisect.
- There's this awkward directory structure of `/serenity/serenity-git`
and `/serenity/out`.
The Dockerfile is immensely useful for building SerenityOS in a
containerized environment, separate from the host's environment. If we
want to automate builds, we can always use CI or extend this image to
do so. For now, let's remove the `git clone` and associated actions.
Fixes#9310.
Right now, this is a bit of a hack. We can't set a keymap to only apply
to the test area, so we set the system keymap instead, while also
keeping track of the "real" current keymap. Whenever the settings are
applied, we update what that "real" keymap is, and when we exit, we
revert to that keymap.
Basically, it behaves as you would expect, apart from it also affecting
other applications you are typing in while the KeyboardSettings window
is open with a different keymap selected.
This is functionally the same as before, as selecting a tab fires Show
and HideEvents. But this way, we don't need to directly access the
TabWidget, which will make using SettingsWindow simpler.
The FooSettings apps have quite a lot of boilerplate just around
creating a tabbed window with the same styling and the same row of
buttons along the bottom. So, let's extract that out into a class we can
reuse! :^)
You create a SettingsWindow instead of a regular Window, passing a title
and a flag to determine if a "Defaults" button is shown. Then call
add_tab() to add tabs to it. Tabs are widgets extending
SettingsWindow::Tab, which has methods for saving and resetting the
values.
For an empty glyph (all pixels initially clear), this makes no
difference. However, if the glyph for the selected code point already
contains some set pixels, pasting used to "add" the set pixels, instead
of overwriting.
An image document is the synthetic DOM::Document we create to wrap an
image when you open the URL of an image directly in a web view.
The path that creates these documents will now also call out to the
separate ImageDecoder process for the actual decoding work.
This saves user code from having to parse the numbers, as we already did
that while Tokenizing. :^)
As a bonus, we now round extremely large integers to the closest
available value, like the spec tells us to.
Previously if a commit message contained any carriage returns it would
correctly fail the 'contains CRLF line breaks' test, but it would also
report 'Commit message lines are too long' and 'Commit title ends in a
period', even if neither is true.
As noted by ECMA-402, if a supported locale contains all of a language,
script, and region subtag, then the implementation must also support the
locale without the script subtag. The most complicated example of this
is the zh-TW locale.
The list of locales in the CLDR database does not include zh-TW or its
maximized zh-Hant-TW variant. Instead, it inlcudes the zh-Hant locale.
However, zh-Hant-TW is listed in the default-content locale list in the
cldr-core package. This defines an alias from zh-Hant-TW to zh-Hant. We
must then also support the zh-Hant-TW alias without the script subtag:
zh-TW. This transitively maps zh-TW to zh-Hant, which is a case quite
heavily tested by test262.
Previously, we were just copying the locale data into default-content
locales (for example, copying the "en" data into "en-US"). Instead, we
can just define the default-content locales as aliases to their main
locales.
This will be used for locale aliases as well. Also rename the "property"
field in this struct to "name", as it no longer is only used for
property aliases.
Coalesce feature is enabled by default when using
the program. Any number of lines identical to the preceding line
will be replaced by a single asterik.
