The mappings are exposed via `Unicode::code_point_decomposition(u32)`
and `Unicode::code_point_decompositions()`, the latter being useful for
reverse searching a code point from its decomposition.
The normalization code does not make use of `Quick_Check` props (https://www.unicode.org/reports/tr44/#Decompositions_and_Normalization),
meaning no quick check optimizations.
Currently the default is false, but this is not the best strategy
for most filters producing artifacts on the borders, and wrap-around
option ends up being better, producing less artifacts.
This prevents items from being put in the overflow menu, even though
there is still enough space for all items to be shown, because the
overflow button does not take up space when it is not needed.
By making proper use of the dynamic layout system, the Breadcrumbbar can
now shrink below its current (grown) size again, while still ensuring
that no icon gets cut off.
When items are sent to the overflow menu one by one, it can happen that
buttons that are heavily related, and don't make sense without one
another (either visually or logically) are separated.
This new option enables the developer to choose the "grouping"
behavior, of sending all items that are not separated to the overflow
menu together, as soon as one of them doesn't have enough space to be
displayed. (provided the toolbar is set as collapsible)
Previously if the user closed the last open tab in the last TabWidget
then the open file action would stop working until they explicitly
went to the View menu and added a new editor group.
Before this commit there was an attempt at preventing the user to
close the last open tab by hiding its close button, this didn't
account for the many other ways one could close it though.
Previously when trying to open a file from the tree view the file
would open in the currently selected tab, substituting the file
we were previously reading.
This change makes it so that clicking on a file from the tree view
opens it in a new tab, or selects the tab containing that file if
it's already open in the selected editor group.
This will allow Ladybird to use IPC::Connection without having an
actively running Core::EventLoop.
The abstraction here is not great, and we should think of something
nicer, but we have to start somewhere.
This patch adds WebView::ViewImplementation with all the
`notify_server_did_this_or_that()` functions from OOPWV.
This will allow us to share code between different web views, paving the
way for a Qt widget in Ladybird that can talk to a WebContent process.
Our IPC protocol currently relies on the behavior of recvfd() and
sendfd() on SerenityOS, which provide an out-of-band queue that can be
accessed independently of the in-band data stream.
To make LibIPC usable on other platforms, this patch adds a mechanism
where IPC::Connection can be given a dedicated socket for FD passing.
This gives us the same behavior as the syscalls on SerenityOS, without
having to change the protocol implementation.
With the addition of the 'fetch params' struct, the single ownership
model we had so far falls apart completely.
Additionally, this works nicely for FilteredResponse's internal response
instead of risking a dangling reference.
Replacing the public constructor with a create() function also found a
few instances of a Request being stack-allocated!
Doesn't use them in libc headers so that those don't have to pull in
AK/Platform.h.
AK_COMPILER_GCC is set _only_ for gcc, not for clang too. (__GNUC__ is
defined in clang builds as well.) Using AK_COMPILER_GCC simplifies
things some.
AK_COMPILER_CLANG isn't as much of a win, other than that it's
consistent with AK_COMPILER_GCC.
This includes punting on the actual file picker implementation all the
way out to the PageClient. It's likely that some of the real details
should be implemented somewhere closer, like the BrowsingContext or the
Page, but we'll get there.
For now, this allows https://copy.sh/v86 to load the emulation of the
preselected images all the way until it hits a call to
URL.createObjectURL.
We parse the arguments that come in, but since we don't yet track
scrollable overflow, we can't do the full "scroll an element into view"
algorithm. For now, we just call out to the PageClient and ask it to
bring the nearest principal box into the visible viewport.
When we have nested flexbox layouts within one another, and the child
context wants to call up to the parent context and ask for help with
dimensioning the child flex container, we now simply do nothing.
As far as I can tell, this works out just fine, since the child flex
container will already be dimensioned by the flex layout algorithm.
