summaryrefslogtreecommitdiff
path: root/Userland/Libraries/LibWeb/Painting/ProgressPaintable.h
AgeCommit message (Collapse)Author
2023-01-11LibWeb: Make the paint tree GC-allocatedAndreas Kling
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.
2022-03-16LibWeb: Refactor all LabelableNode subclasses + input event handling :^)sin-ack
This commit is messy due to the Paintable and Layout classes being tangled together. The RadioButton, CheckBox and ButtonBox classes are now subclasses of FormAssociatedLabelableNode. This subclass separates these layout nodes from LabelableNode, which is also the superclass of non-form associated labelable nodes (Progress). ButtonPaintable, CheckBoxPaintable and RadioButtonPaintable no longer call events on DOM nodes directly from their mouse event handlers; instead, all the functionality is now directly in EventHandler, which dispatches the related events. handle_mousedown and related methods return a bool indicating whether the event handling should proceed. Paintable classes can now return an alternative DOM::Node which should be the target of the mouse event. Labels use this to indicate that the labeled control should be the target of the mouse events. HTMLInputElement put its activation behavior on run_activation_behavior, which wasn't actually called anywhere and had to be manually called by other places. We now use activation_behavior which is used by EventDispatcher. This commit also brings HTMLInputElement closer to spec by removing the did_foo functions that did ad-hoc event dispatching and unifies the behavior under run_input_activation_behavior.
2022-03-11LibWeb: Move PaintingBox to its own .cpp and .h filesAndreas Kling
2022-03-11LibWeb: Make Paintable ref-countedAndreas Kling
This will allow us to use a protective NonnullRefPtr to keep paintables alive while running arbitrary JavaScript in response to events.
2022-03-11LibWeb: Split Paintable into Paintable and PaintableBoxAndreas Kling
To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-11LibWeb: Let Paintable perform the paintingAndreas Kling
This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.