Struct druid::WidgetPod

pub struct WidgetPod<T, W> { /* private fields */ }

A container for one widget in the hierarchy.

Generally, container widgets don’t contain other widgets directly, but rather contain a WidgetPod, which has additional state needed for layout and for the widget to participate in event flow.

WidgetPod will translate internal Druid events to regular events, synthesize additional events of interest, and stop propagation when it makes sense.

This struct also contains the previous data for a widget, which is essential for the update method, both to decide when the update needs to propagate, and to provide the previous data so that a widget can process a diff between the old value and the new.

Implementations

impl<T, W: Widget<T>> WidgetPod<T, W>

pub fn new(inner: W) -> WidgetPod<T, W>

Create a new widget pod.

In a widget hierarchy, each widget is wrapped in a WidgetPod so it can participate in layout and event flow. The process of adding a child widget to a container should call this method.

pub fn is_initialized(&self) -> bool

Returns true if the widget has received LifeCycle::WidgetAdded.

pub fn has_focus(&self) -> bool

Returns true if widget or any descendent is focused

pub fn is_active(&self) -> bool

The “active” (aka pressed) status of a widget.

Active status generally corresponds to a mouse button down. Widgets with behavior similar to a button will call set_active on mouse down and then up.

The active status can only be set manually. Druid doesn’t automatically set it to false on mouse release or anything like that.

There is no special handling of the active status for multi-pointer devices.

When a widget is active, it gets mouse events even when the mouse is dragged away.

pub fn has_active(&self) -> bool

Returns true if any descendant is active.

pub fn is_hot(&self) -> bool

The “hot” (aka hover) status of a widget.

A widget is “hot” when the mouse is hovered over it. Some Widgets (eg buttons) will change their appearance when hot as a visual indication that they will respond to mouse interaction.

The hot status is automatically computed from the widget’s layout rect. In a container hierarchy, all widgets with layout rects containing the mouse position have hot status. The hot status cannot be set manually.

There is no special handling of the hot status for multi-pointer devices.

Note: a widget can be hot while another is active (for example, when clicking a button and dragging the cursor to another widget).

pub fn id(&self) -> WidgetId

Get the identity of the widget.

pub fn layout_requested(&self) -> bool

This widget or any of its children have requested layout.

pub fn set_origin(&mut self, ctx: &mut impl ChangeCtx, origin: Point)

Set the origin of this widget, in the parent’s coordinate space.

A container widget should call the [Widget::layout] method on its children in its own [Widget::layout] implementation, and then call set_origin to position those children.

The changed origin won’t be fully in effect until LifeCycle::ViewContextChanged has finished propagating. Specifically methods that depend on the widget’s origin in relation to the window will return stale results during the period after calling set_origin but before LifeCycle::ViewContextChanged has finished propagating.

The widget container can also call set_origin from other context, but calling set_origin after the widget received LifeCycle::ViewContextChanged and before the next event results in an inconsistent state of the widget tree.

The child will receive the LifeCycle::Size event informing them of the final Size.

pub fn layout_rect(&self) -> Rect

Returns the layout Rect.

This will be a Rect with a Size determined by the child’s layout method, and the origin that was set by set_origin.

pub fn paint_rect(&self) -> Rect

Get the widget’s paint Rect.

This is the Rect that widget has indicated it needs to paint in. This is the same as the layout_rect with the paint_insets applied; in the general case it is the same as the layout_rect.

pub fn paint_insets(&self) -> Insets

Return the paint Insets for this widget.

If these Insets are nonzero, they describe the area beyond a widget’s layout rect where it needs to paint.

These are generally zero; exceptions are widgets that do things like paint a drop shadow.

A widget can set its insets by calling set_paint_insets during its layout method.

pub fn compute_parent_paint_insets(&self, parent_size: Size) -> Insets

Given a parents layout size, determine the appropriate paint Insets for the parent.

This is a convenience method to be used from the layout method of a [Widget] that manages a child; it allows the parent to correctly propagate a child’s desired paint rect, if it extends beyond the bounds of the parent’s layout rect.

pub fn baseline_offset(&self) -> f64

The distance from the bottom of this widget to the baseline.

impl<T: Data, W: Widget<T>> WidgetPod<T, W>

pub fn paint_raw(&mut self, ctx: &mut PaintCtx<'_, '_, '_>, data: &T, env: &Env)

Paint a child widget.

Generally called by container widgets as part of their [Widget::paint] method.

Note that this method does not apply the offset of the layout rect. If that is desired, use paint instead.

pub fn paint(&mut self, ctx: &mut PaintCtx<'_, '_, '_>, data: &T, env: &Env)

Paint the widget, translating it by the origin of its layout rectangle.

This will recursively paint widgets, stopping if a widget’s layout rect is outside of the currently visible region.

pub fn paint_always(&mut self, ctx: &mut PaintCtx<'_, '_, '_>, data: &T, env: &Env)

Paint the widget, even if its layout rect is outside of the currently visible region.

pub fn layout(
    &mut self,
    ctx: &mut LayoutCtx<'_, '_>,
    bc: &BoxConstraints,
    data: &T,
    env: &Env
) -> Size

Compute layout of a widget.

Generally called by container widgets as part of their layout method.

pub fn event(
    &mut self,
    ctx: &mut EventCtx<'_, '_>,
    event: &Event,
    data: &mut T,
    env: &Env
)

Propagate an event.

Generally the event method of a container widget will call this method on all its children. Here is where a great deal of the event flow logic resides, particularly whether to continue propagating the event.

pub fn lifecycle(
    &mut self,
    ctx: &mut LifeCycleCtx<'_, '_>,
    event: &LifeCycle,
    data: &T,
    env: &Env
)

Propagate a LifeCycle event.

pub fn update(&mut self, ctx: &mut UpdateCtx<'_, '_>, data: &T, env: &Env)

Propagate a data update.

Generally called by container widgets as part of their update method.

impl<T, W: Widget<T> + 'static> WidgetPod<T, W>

pub fn boxed(self) -> WidgetPod<T, Box<dyn Widget<T>>>

Box the contained widget.

Convert a WidgetPod containing a widget of a specific concrete type into a dynamically boxed widget.

impl<T, W> WidgetPod<T, W>

pub fn widget(&self) -> &W

Return a reference to the inner widget.

pub fn widget_mut(&mut self) -> &mut W

Return a mutable reference to the inner widget.