You can now press Ctrl+Shift+A in any LibGUI application and we'll give
you a command palette dialog where you can search for context-relevant
actions by name (via the keyboard.)
The set of actions is currently the same one you'd access via keyboard
shortcuts. In the future, we'll probably want to add APIs to allow
richer integrations with this feature.
While the rows are filtered, we can't just return data from column 0
every time, since that breaks underlying multi-column models.
Instead, simply forward the incoming index.
When a git patch that doesn't apply is encountered, start a git am
session and _then_ drop the user in it instead of expeting the user to
start the session on their own.
Also prompt for leftover files and delete them if the user does not want
them.
In the one place this will be used, we will know that the NumberFormat
object is non-null. So return a reference, as the AO it is passed off to
also expects a reference.
As we didn't (and still don't) have Intl.PluralRules when we implemented
Intl.NumberFormat, we use a locale-unaware basic implementation to pick
a pattern based on a number's value. Templatize this method for now to
work other other format-like structures (will be used for relative-time
formatting).
Relative-time format patterns are of one of two forms:
* Tensed - refer to the past or the future, e.g. "N years ago" or
"in N years".
* Numbered - refer to a specific numeric value, e.g. "in 1 year"
becomes "next year" and "in 0 years" becomes "this year".
In ECMA-402, tensed and numbered refer to the numeric formatting options
of "always" and "auto", respectively.
This sets up the generator plumbing to create the relative-time data
files. This data could probably be included in the date-time generator,
but that generator is large enough that I'd rather put this tangentially
related data in its own file.
Much of the `Clipper` class can be made free functions and their scope
limited.
The purpose of this is to prepare the interface for a change to more
compile-time dispatch.
Clearing the `m_alpha_blend_factors` is performed manually and in
separate steps. This is error prone for future developers. The
behavior is to reset the entire `struct` to the same state as default
initialization, so this simplifies it to do just that.
Each of the material faces is copied member by member then the copied
material state is passed by `const&` to another function, then
destroyed.
This is changed to simply passing the material state directly without
copying.
There is a loop over the lights in which each light state is copied
member by member then the copied light state is passed by `const&` to
another function, then destroyed.
This is changed to simply passing the light state directly without
copying.
Previously, we were breaking up digits into groups without regard for
the locale's minimumGroupingDigits value in the CLDR. This value is 1 in
most locales, but is 2 in locales such as pl-PL. What this means is that
in those locales, the group separator should only be inserted if the
thousands group has at least 2 digits. So 1000 is formatted as "1,000"
in en-US, but "1000" in pl-PL. And 10000 is "10,000" in en-US and
"10 000" in pl-PL.
For example, say you try to create a Value from an Array and forgot to
include LibJS/Runtime/Array.h. This would cause the boolean constructor
to be used instead of a compile error.
We were marking the execing thread as Runnable near the end of
Process::do_exec().
This was necessary for exec in processes that had never been scheduled
yet, which is a specific edge case that only applies to the very first
userspace process (normally SystemServer). At this point, such threads
are in the Invalid state.
In the common case (normal userspace-initiated exec), making the current
thread Runnable meant that we switched away from its current state:
Running. As the thread is indeed running, that's a bogus change!
This created a short time window in which the thread state was bogus,
and any attempt to block the thread would panic the kernel (due to a
bogus thread state in Thread::block() leading to VERIFY_NOT_REACHED().)
Fix this by not touching the thread state in Process::do_exec()
and instead make the first userspace thread Runnable directly after
calling Process::exec() on it in try_create_userspace_process().
It's unfortunate that exec() can be called both on the current thread,
and on a new thread that has never been scheduled. It would be good to
not have the latter edge case, but fixing that will require larger
architectural changes outside the scope of this fix.
