| Age | Commit message (Collapse) | Author |
|---|
|
These are not needed anymore since the introduction of the new
get_root_session_id syscall.
|
|
The undo code here was just replacing the new text with the new text.
Now we actually save the old text and use that instead. :^)
|
|
No new features, but it sure makes things look more fancy. :^)
|
|
There isn't much layout right now, but it felt very wrong to not have
the GML editor use GML. :^)
|
|
Before we used the value of days which may also contain a fraction.
The algorithm expects it to be an integer.
This was addressed upstream in: tc39/proposal-temporal@02379da
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This starts moving code equally shared between the OOPWV and Ladybird
WebContentView implementations to WebView::ViewImplementation, beginning
with the client state.
|
|
|
|
|
|
Before this patch, we were expressing the current selection as a range
between two points in the layout tree. This was a made-up concept I
called LayoutRange (2x LayoutPosition) and as it turns out, we don't
actually need it!
Instead, we can just use the Selection API from the Selection API spec.
This API expresses selection in terms of the DOM, and we already had
many of the building blocks implemented.
To ensure that selections get visually updated when the underlying Range
of an active Selection is programmatically manipulated, Range now has
an "associated Selection". If a range is updated while associated with
a selection, we recompute layout tree selection states and repaint the
page to make it user-visible.
|
|
We do what other browsers do and create a selection anchored at the
document's body element.
|
|
Instead of sifting through the layout tree to extract the selected text,
look at the DOM selection instead.
Note that we can't just stringify the DOM Range, as that would include
non-visible things (like the content of <style> elements, etc.) so we
run it through an ad-hoc variant of the range stringification algorithm.
This can probably be factored better, but it's a start. :^)
|
|
This is a lot smoother than calling the throwsy get_range_at() API,
especially since we know there at most 1 range in the selection.
|
|
Largely based on the Ladybird implementation in 0cc151b.
|
|
If we failed to decode a sample we'd presumably want to tell the user,
and we definitely don't want to just go into another round of decoding
somewhere in the middle of a broken sample.
|
|
Especially if buffered streams are involved, not filling the span
completely can also mean that we just ran out of filled buffer space and
we need to refill it on the beginning of the next read call.
|
|
|
|
|
|
|
|
|
|
The size of the preview shown by the lasso tool now scales with the
current zoom level.
|
|
This utility when given a .tff font provides options for disassembling:
- The 'fpgm' table, this a program that's run once when the font is
loaded. It's used to define instructions and functions used by used
by other programs.
- The 'prep' table, this is a general program that's run when ever
the font size (or other properties) changes.
- And the programs associated with any individual glyph.
The disassembly is printed in a format that matches the examples from:
https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions
I'm mainly adding this because I think it's neat to be able to look
at these things, and think it'll be helpful for debugging an
interpreter.
With this you can see that all of the LiberationSerif-XXX.tff fonts in
Serenity have these programs ready to go.
|
|
These probably won't need to stick around forever, but will be helpful
for creating some debug utilities.
|
|
These contain the font and CVT programs respectively.
|
|
This defines all the OpenType opcodes/instructions from the
specification:
https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions
Each instructions has mnemonic and a range of possible opcodes (as some
of the bits are pretty much immediate value flags).
There's a little helper Instruction struct for accessing the flags and
any associated data (in the case of PUSH instructions).
Then the InstructionStream provides a way of iterating over all the
instructions in some bytes.
|
|
|
|
|
|
This was unintuitive, and only useful in a few cases. In the majority,
users had to immediately call `stop()`, and several who did want the
timer started would call `start()` on it immediately anyway. Case in
point: There are only two places I had to add a manual `start()`.
|
|
clang-format sure has some interesting opinions about where to put a
method call that comes after a lambda. :thonk:
|
|
The FIXMEs must flow!
|
|
This provides a list of well-known directories containing font files,
e.g. for use with Gfx::FontDatabase::load_all_fonts_from_path().
|
|
|
|
Previously, only the preview frame was updated without changing any
values in the right panel or even a file path in the window title.
|
|
Drops were handled only by the Preview Widget previously. It probably
made a little more sense before the program redesign, as it took most of
window the space, but now honestly this idea doesn't hold up that well.
|
|
|
|
This was *probably* already safe, but there's no harm in making sure
the cached pointer gets marked during GC.
|
|
|
|
|
|
This simplifies the ownership model between DOM/layout/paint nodes
immensely by deferring to the garbage collector for figuring out what's
live and what's not.
|
|
|
|
This hopefully makes EventLoop easier to understand.
|
