| Age | Commit message (Collapse) | Author |
|---|
|
Match the spec nomenclature.
|
|
|
|
This helps us to get from a Window to the containing Page, without
clients having to go through Document.
|
|
This better matches the spec nomenclature. Note that we don't yet
*retrieve* the active document according to spec.
|
|
This patch converts all the usage of AK::String around sys$execve() to
using KString instead, allowing us to catch and propagate OOM errors.
It also required changing the kernel CommandLine helper class to return
a vector of KString for the userspace init program arguments.
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/899cc24
|
|
|
|
This is a feature I missed from Photoshop: it sets the scale and
position so that the image fits (it's longest dimension) into
the editor view. There's a 5% border left around the image to
provide context. This is just arbitrary seemed like the right
amount after some trial and error.
|
|
Previously EraseTool would only let you have hard lines, similar
to PenTool. After inheriting from BrushTool in previous commits,
making the eraser (optionally) behave like a brush is much easier.
We only need to change how the colors are handled for the hardness,
which is why the `draw_point()` call is a bit more involved. Just
blending the colors doesn't work here since we actually want to
replace the previous color, unlike in BrushTool where we are just
layering the color on top.
|
|
This removes all the code to handle events that was essentially
duplicated from BrushTool anyway :^)
I've also renamed "thickness"->"size" to have consistent
terminology.
|
|
Most of the logic implemented in PenTool was the same as BrushTool
anyway, with the only difference being how the actual lines were
drawn at the end. We now just override the `draw_line()` and
`draw_point()` methods instead.
We don't strictly need to override `draw_line()` here, but that
would just result in repeated calls to `draw_point()`, which is
wasteful.
Also renamed "thickness"->"size" to have consistent terminology.
|
|
The BrushTool is very cool, but it doesn't allow us to re-use any
of the code in other classes. Many of the other tools have duplicated
code for handling mouse events / keeping track of previous location,
etc.
This commit sets up BrushTool so that other tools can inherit from
it and override some virtual functions to allow similar behavior
without re-writing the code to keep track of mouse positions, etc.
In particular, we add public setters/getters for `size` and
`hardness` properties, and make `draw_point()` and `draw_line()`
virtual so that derived classes can override them.
Note: We still pass in `color` as a parameter for `draw_line()` and
`draw_point()` instead of using `color_for()` directly because it
doesn't really make sense to be constantly asking the ImageEditor
for the color when it's not really changing (for instance along all
the points of a line)
|
|
Sometimes you want to draw a straight line between 2 points, but
using the nice-looking brush we have instead of the hard line we
would get using the LineTool.
This patch adds the ability to click somewhere with the brush, and
then Shift+click somewhere else to draw a line between the two
points using the brush stroke. Seems like an obvious addition
considering we already have a helper function to draw lines :^)
|
|
This is required by some programs, notably python's socket module, which
fails to compile without this definition.
|
|
|
|
The BFS implementation for BucketTool's flood-fill had sitations
which could result in infinite loop, causing OOM crashes due to
the queue growing unbounded. The way to fix this is to keep track
of the pixels we have already visited in the flood-fill algorithm
and ignore those if we ever encounter them again.
This also fixes the crashing issue from #9003. We still need a
better way to account for transparency, but that is beyond the scope
of this commit, and this issue still exists without any transparent
pixels.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This will restrict 3DFileViewer's access to the file system.
3DFileViewer loads a texture based on the path of the model loaded, this
will request access to the texture file before loading.
|
|
|
|
This will share functionality between the load from path and load from
memory functions.
|
|
Previously, the title of an unnamed file would just disappear from
the editor label if you started typing.
|
|
The existing behaviour is that filename_textbox is cleared if a node of
the wrong type is selected. Here we reflect that state update in the
state of the ok_button.
This change helps the user to avoid confirming (and seeing an alert) if
they press "Open" after clicking on an invalid node.
|
|
Call HTML::EventLoop::spin_until() from the HTML parser when deciding
whether we can run a script yet.
Note that spin_until() actually doesn't do any work yet.
|
|
This will be used by the HTML parser to determine whether it's okay to
start running a script.
Note that we don't actually count the script-blocking style sheets yet.
This patch only adds a the checking mechanism for the parser.
|
|
This is the "browsing context container document" from the spec.
|
|
We already have a base class for frame elements that we call
BrowsingContextContainer. This patch makes BrowsingContext::container()
actually return one of those.
This makes us match the spec names, and also solves a FIXME about having
a shared base for <frame> and <iframe>. (We already had the shared base,
but the pointer we had there wasn't tightly typed enough.)
|
|
|
|
|
|
This roughly models the "queue an element task" algorithm from the spec.
For safety, this captures a strong reference to the element, and then
bundles that with a callback into a HTML::Task (that we then queue up.)
|
|
Since we can't simply give HTML::EventLoop control of the whole program,
we have to integrate with Core::EventLoop.
We do this by having a single-shot 0ms Core::Timer that we start when
a task is added to the queue, and restart after processing the queue and
there are still tasks in the queue.
|
|
This will be required for event loop processing.
|
|
There are three types of event loop: window, worker and worklet.
For now, we only have window event loops.
|
|
|
|
|
|
|
|
|
|
This patch attaches a HTML::EventLoop to the main thread JS::VM used
for JavaScript bindings in the web engine.
The goal here is to model the various task scheduling mechanisms of the
HTML specification.
|
|
This will be used by LibWeb to attach web engine specific stuff that
LibJS doesn't need to know about.
|
|
|
|
|
|
|
|
This is especially helpful where we already pass StringView literals
and only compare them with others, e.g. overflow and largest/smallest
unit, in which case there's no need to actually allocate a string.
|
|
When I play Pong, I don't really pay attention to whether my mouse is in
the Pong window. That means that sometimes, annoyingly, the window loses
my mouse, and I lose control of the paddle. Gasp! D:
This commit teaches Pong the wonders of global mouse tracking, thus
enabling the player to focus solely on the game.
|
|
Previously, LibUnicode would store the values of a keyword as a Vector.
For example, the locale "en-u-ca-abc-def" would have its keyword "ca"
stored as {"abc, "def"}. Then, canonicalization would occur on each of
the elements in that Vector.
This is incorrect because, for example, the keyword value "true" should
only be dropped if that is the entire value. That is, the canonical form
of "en-u-kb-true" is "en-u-kb", but "en-u-kb-abc-true" does not change
for canonicalization. However, we would canonicalize that locale as
"en-u-kb-abc".
|
