This fixes#6902.
Previously, dragging and dropping multiple files would create a window
for each file or directory that was selected. Now, we combine them and
show one progress window for the whole batch. :^)
You can now list multiple files or directories and they will all be
copied to the destination. :^)
Note that this means you can pass the same file or directory multiple
times. It runs fine, just means that it does unnecessary work. But
figuring out if a file is already queued is probably more hassle than
it's worth, if it's even possible at all due to symlinks.
We don't need to have a dedicated API for creating a VMObject with a
single page, the multi-page API option works in all cases.
Also make the API take a Span<NonnullRefPtr<PhysicalPage>> instead of
a NonnullRefPtrVector<PhysicalPage>.
This also implements the CodePointAt abstract operation. This is needed
to handle invalid code units specific to the JavaScript spec, rather
than e.g. inserting replacement code units. This abstraction is public
because RegExp.prototype will also need it.
LibJS parses JavaScript as UTF-8, so when creating a string, we must
transcode it to UTF-16 to handle encoded surrogate pairs.
For example, consider the following string:
"\ud83d\ude00"
The UTF-8 encoding of this surrogate pair is:
0xf0 0x9f 0x98 0x80
However, LibJS will currently store the two surrogates individually as
UTF-8 encoded bytes, rather than combining the pair:
0xed 0xa0 0xb8, 0xed 0xb8 0x80
These are not equivalent. So, as String.prototype becomes UTF-16 aware,
this encoding will no longer work for abstractions like strict equality.
These methods did not require UTF-16 views, so just add test cases to
ensure they remain correct.
This also adds a couple of FIXME comments on tests that will fail even
with UTF-16 String.prototype support (for reasons such as lack of UTF-16
support in RegExp.prototype and Unicode case folding).
Depending on the values it might be difficult to figure out whether a
value is decimal or hexadecimal. So let's make this more obvious. Also
this allows copying and pasting those numbers into GNOME calculator and
probably also other apps which auto-detect the base.
When changing the theme, there were two Core::ConfigFile instances
(one class scoped -- m_config and one function scoped -- wm_config)
fighting over the file, resulting in not saving the new theme name
to the config. :^(
This makes WindowServer remember selected theme from the menu
after reboot!
