Trait druid::widget::Widget

source ·
pub trait Widget {
    fn paint(&mut self, paint_ctx: &mut PaintCtx<'_, '_>, geom: &Geometry) { ... }
    fn layout(
        &mut self,
        bc: &BoxConstraints,
        children: &[Id],
        size: Option<(f32, f32)>,
        ctx: &mut LayoutCtx
    ) -> LayoutResult { ... } fn mouse(&mut self, event: &MouseEvent, ctx: &mut HandlerCtx<'_>) -> bool { ... } fn mouse_moved(&mut self, x: f32, y: f32, ctx: &mut HandlerCtx<'_>) { ... } fn on_hot_changed(&mut self, hot: bool, ctx: &mut HandlerCtx<'_>) { ... } fn poke(&mut self, payload: &mut dyn Any, ctx: &mut HandlerCtx<'_>) -> bool { ... } fn key(&mut self, event: &KeyEvent, ctx: &mut HandlerCtx<'_>) -> bool { ... } fn anim_frame(&mut self, interval: u64, ctx: &mut HandlerCtx<'_>) { ... } fn on_child_removed(&mut self, child: Id) { ... } }
Expand description

The trait implemented by all widgets.

Provided Methods

Paint the widget’s appearance into the paint context.

The implementer is responsible for translating the coordinates as specified in the geometry.

Participate in the layout protocol.

size is the size of the child previously requested by a RequestChild return.

The default implementation is suitable for widgets with a single child, and just forwards the layout unmodified.

Sent to the widget on mouse event.

Mouse events are propagated in a post-order traversal of the widget tree, culled by geometry. Propagation stops as soon as the event is handled.

Sent to the active or hot widget on mouse move events.

Sent to the widget when its “hot” status changes.

An “escape hatch” of sorts for accessing widget state beyond the widget methods. Returns true if it is handled.

Sent to the widget on key event.

Key events are only sent to the focused widget.

Note that keys that are interpreted as characters are sent twice, first as a Vkey, then as a Char.

This is a fairly thin wrapper over WM messages. Keyboard input will be changing quite a bit when IME is implemented.

Returns true if the event is handled.

Called at the beginning of a new animation frame.

The interval argument is the time in nanoseconds between frames, for the purpose of computing animations. When framerate is steady, it should be exactly the reciprocal of the refresh rate of the monitor. If we are skipping frames, its cumulative sum should approximately track the passage of wall clock time and otherwise should be chosen to optimize for smoothness of animations.

The ideal heuristic for computing this interval is a deep topic, ideally the subject of a blog post when I figure it out.

On the first frame when transitioning from idle to animating, interval will be 0. (This logic is presently per-window but might change to per-widget to make it more consistent).

This method should call invalidate on the context if the visual display updates. In the current implementation, that’s not very useful, but it will become much more so when there’s fine grained invalidation.

The method can also call request_anim_frame to keep the animation running.

Called when a child widget is removed.

Implementors