This tab allows you to view the accessibility tree like you do
the DOM tree. The implementation limited to the role currently,
once we add the name and description calculation algorithm, those
will be displayed here as well. Selections are also not currently
supported.
This patch also stubs out notify_server_did_get_accessiblity_tree in
ladybird since ViewImplementation now has it. However, this feature
is still immature, so just stubbing out in ladybird for now. Once we
have more robust support in Serenity (namely ARIA properties/state
and accessible names and descriptions) we can port this
functionality over.
With this patch, the accessibility tree can be build from the root
node of a document. This can then be serialzed and sent to (soon
to come) consumers.
When we were asked to make a new preview text, we first generated the
whole file in the /tmp directory and then read the first 8 lines to put
them in a text box. This was doing a bit of unnecessary work at first,
but more importantly, didn't work on a given file descriptor from
FileSystemAccessServer as we were copying a file to a filename instead,
meaning that we also had to unveil the whole home directory.
Anyway, previews will be written now to a MemoryStream by the generator,
which will limit to 8 lines. File saves will omit /tmp entirely,
allowing us to tighten program unveil list a little. :^)
This change allows for cursor navigation of a forumula while editing
rather than having to use the mouse to edit the cursor position within
a cell. Tab and Enter still allow you to navigate out of the cell to
next row or columns. :)
A substitution command like "s/x/y/wabc" will now write all substituted
lines to a file called "abc". Note that this is in addition to writing
to stdout.
Previously, if a pattern matched the empty string (e.g. ".*"), it would
match the string twice instead of once. Among other issues, this caused
a Regex replacement to duplicate its expected output, since it would
replace "both" empty matches.
Rip that bandaid off!
This does the following, in one big, awkward jump:
- Replace all uses of `set_main_widget<Foo>()` with the `try` version.
- Remove `set_main_widget<Foo>()`.
- Rename the `try` version to just be `set_main_widget` because it's now
the only one.
The majority of places that call `set_main_widget<Foo>()` are inside
constructors, so this unfortunately gives us a big batch of new
`release_value_but_fixme_should_propagate_errors()` calls.
These flags are always 0 in practice in all profiles I've seen so far,
but hey, probably nice to dump them anyways.
And hey, it's just 86 lines to print 4 bits.
When laying out abspos boxes, we compute the height twice: before and
after the inside of the box has been laid out.
The first pass allows percentage vertical values inside the box to be
resolved against the box's height. The second pass resolves the final
used value for the height of the box itself.
In cases where the box height depends on the results of inside layout,
we were incorrectly setting the box to having a definite zero height.
This led to incorrect results when sizing an abspos flex container,
since the FFC sizes containers (in row layouts) based on whether the
container has a definite height.
To avoid this problem, this patch adds an enum so we can differentiate
between the two abspos height computation passes. If the first pass
discovers a dependency on the inside layout, we simply bail out of
computing the height, leaving it as indefinite. This allows the FFC
to size its container correctly, and the correct height gets set by
the second pass.
Always computing computing the md5 takes some time, but most
icc profiles are small. So that's probably fine.
If this ends up being a perf problem in the future, or if it ends up
rejecting tons of embedded proiles from images, we can row it back.
But let's see if we can get away with this first.
I checked that they are zero for all profiles in Compact-ICC-Profiles
and for all .icc files in /Library/ColorSync and
/System/Library/ColorSync on my Mac (running macOS 12.6.2).
PDF allows for named destinations to be provided as string. These can be
either found in the Dests dictionary in the document catalogue (as
already implemented), or in the Name Tree specified by the Dests key in
the Names dictionary of the document catalogue (missing).
This commit adds this missing case. Once the named destination is found
in the name tree, its value is interpreted just like in the first case,
so a new utility method encapsulates the common behavior.
Name Trees are hierarchical, string-keyed, sorted-by-key dictionary
structures in PDF where each node (except the root) specifies the bounds
of the values it holds, and either its kids (more nodes) or the
key/value pairs it contains.
This commit implements a series of lookup calls for finding a key in
such name trees. This implementation follows the tree as needed on each
lookup, but if that becomes inefficient in the long run we can switch to
creating a HashMap with all the contents, which as a drawback will
require more memory.
Being both of them containers, these classes already offered a set of
methods to retrieve an inner element by key or index, respectively, with
different methods for the different subtypes of the PDF::Object type
returning the element cast to the correct type pointer. On top of
that, DictObject offered an additional method to obtain an element as an
Object pointer.
While these methods were useful, they have some shortcomings:
* They always take a Document pointer to first perform an object
resolution, in case the element is a Reference. This is not always
necessary though, as there are values that are always meant to be
immediate, and hence the resolution lookup adds overhead.
* There was no easy way to get an individual Object element from an
ArrayObject like there is in DictObject. This makes it difficult to
obtain such values, as one first needs to call dict.get() to get a
Value, then cast it manually to a NonnullRefPtr<Object>.
This commit fixes these two issues by:
* Adding a new method that returns an Object for a given index.
* Adding overloads for this new method, and all the existing methods
described above, that do *not* take a Document, and therefore do
*not* perform an object resolution lookup.
This functionality was previously part of the resolve_to() Document
method, and thus only available only when resolving objects through the
Document class. There are many use cases where this casting can be used,
but no resolution is needed.
This commit moves this functionality into a new cast_to function, and
makes the resolve_to function call it internally. With this new function
in place we can now offer new versions of DictObject::get_* and
ArrayObject::get_*_at that don't perform Document resolution
unnecessarily when not required.
Destination arrays contain a page number, a mode name, and parameters
specific to that mode. In many cases these parameters can be set to
"null", which our code wasn't taking into consideration.
This commit parses these parameters taking into account whether they are
null or actual numbers, and stores them as Optional<float> instead of
plain floats. The parameters are not yet used anywhere else other than
when formatting a Destination object, so the change is fairly small.
It is now possible to scale the current layer using the move tool from
all four corners of the layer boundary. Previously scaling was only
possible from the bottom right of the image.
Repeatedly allocation a new Card object is unnecessary, and makes
propagating OOM awkward. We also don't need a full card, just which
suit/rank it is and its position. So, let's save all the extra
allocation and just paint the card bitmap directly.
For example, in Solitaire, the vertical normal stacks cover the suit of
all but the topmost card in the stack. To see the suit of covered cards
the user currently has to move the cards on top of them out of the way.
This adds an API for games to set a card at a location to be previewed,
which will draw that card on top of all other cards without moving it.
This patch also updates corresponding functions from
`LibFileSystemAccessServerClient`.
From the FileSystemAccessClient point of view, it only makes the server
take `Core::Stream::OpenMode` instead of `Core::OpenMode`. So, `enum`
conversions only happen within deprecated functions and not in the new
`Core::Stream` friendly API.
On the server side, it just removes two usages of `Core::File::open()`.