Loading libunicodedata.so will require dlopen(), which in turn requires
mmap(). The 'prot_exec' pledge is needed for this.
Further, the .so itself must be unveiled for reading. The "real" path is
unveiled (libunicodedata.so.serenity) as the symlink (libunicodedata.so)
itself cannot be unveiled.
Derivatives of Core::Object should be constructed through
ClassName::construct(), to avoid handling ref-counted objects with
refcount zero. Fixing the visibility means that misuses like this are
more difficult.
From what I think, the array should consist of point indexes that have
been matched instead of just the last one.
For example, these are the array contents after searching 'file' for
'File Manager':
- Before: [ 3 ]
- Now: [ 0, 1, 2, 3 ]
Besides that, this greatly improves the scoring logic, as it can now
calculate bonuses.
Closes: #8310
SonarCloud flagged the read of the matches array as a potential garbage
read. I don't believe the case it flagged was possible to reach due to
how the code is structured, however we should really just be zero
initializing these stack arrays.
Previously, Assistant was able to re-execute itself due to a quirk in
the global cursor tracking logic, it seems.
Now it has become necessary to explicitly drop the lockfile before
activating the new Assistant instance.
Alternatively, this has always been a latent bug that only now has
become more likely.
This allows for typing [8] instead of [8, 8, 8, 8] to specify the same
margin on all edges, for example. The constructors follow CSS' style of
specifying margins. The added constructors are:
- Margins(int all): Sets the same margin on all edges.
- Margins(int vertical, int horizontal): Sets the first argument to top
and bottom margins, and the second argument to left and right margins.
- Margins(int top, int vertical, int bottom): Sets the first argument to
the top margin, the second argument to the left and right margins,
and the third argument to the bottom margin.
Previously the argument order for Margins was (left, top, right,
bottom). To make it more familiar and closer to how CSS does it, the
argument order is now (top, right, bottom, left).
While typing, we get the results from each provider asynchronously.
Previously, we were updating the UI for each result size,
which was causing a lot of flickering.
This fix creates a small timer to bundle the results
and reduce the number of UI updates per input.
I found myself accidentally opening two assistants at once with the
Window+Space shortcut. Since only one assistant window is usable at the
same time, I made assistant only spawn 1 instance at most.
Using fstatat() allows the kernel to do relative path resolution as
opposed to absolute path resolution, which is significantly faster
and allows us to build the path cache sooner. :^)
Result classes now return their bitmap via a virtual Gfx::Bitmap*
getter. This effectively makes bitmap fetching lazier, since only
results that end up on screen actually get asked for their bitmap.
This drastically reduces the amount of work done by the FileProvider
background worker.
When searching in Assistant, we now dispatch some background jobs to
query the whole filesystem. Activating a result will use the Desktop
launcher's default way of opening that file or directory.
When launching Terminal via Taskbar we change to the users home
directory. For consistency, let's also `chdir` to `/home/anon` when
launching apps via Assistant's AppProvider.
If there are no search results in the list, we shouldn't do anything
when you try to active the selected result, since there isn't one.
Fix this by using an Optional<size_t> to store the selected index.
