[][src]Trait druid::Widget

pub trait Widget<T> {
    fn event(
        &mut self,
        ctx: &mut EventCtx,
        event: &Event,
        data: &mut T,
        env: &Env
fn lifecycle(
        &mut self,
        ctx: &mut LifeCycleCtx,
        event: &LifeCycle,
        data: &T,
        env: &Env
fn update(&mut self, ctx: &mut UpdateCtx, old_data: &T, data: &T, env: &Env);
fn layout(
        &mut self,
        ctx: &mut LayoutCtx,
        bc: &BoxConstraints,
        data: &T,
        env: &Env
    ) -> Size;
fn paint(&mut self, ctx: &mut PaintCtx, data: &T, env: &Env); }

The trait implemented by all widgets.

All appearance and behavior for a widget is encapsulated in an object that implements this trait.

The trait is parametrized by a type (T) for associated data. All trait methods are provided with access to this data, and in the case of event the reference is mutable, so that events can directly update the data.

Whenever the application data changes, the framework traverses the widget hierarchy with an update method. The framework needs to know whether the data has actually changed or not, which is why T has a Data bound.

All the trait methods are provided with a corresponding context. The widget can request things and cause actions by calling methods on that context.

In addition, all trait methods are provided with an environment (Env).

Container widgets will generally not call Widget methods directly on their child widgets, but rather will own their widget wrapped in a WidgetPod, and call the corresponding method on that. The WidgetPod contains state and logic for these traversals. On the other hand, particularly light-weight containers might contain their child Widget directly (when no layout or event flow logic is needed), and in those cases will call these methods.

As a general pattern, container widgets will call the corresponding WidgetPod method on all their children. The WidgetPod applies logic to determine whether to recurse, as needed.

Required methods

fn event(&mut self, ctx: &mut EventCtx, event: &Event, data: &mut T, env: &Env)

Handle an event.

A number of different events (in the Event enum) are handled in this method call. A widget can handle these events in a number of ways: requesting things from the EventCtx, mutating the data, or submitting a Command.

fn lifecycle(
    &mut self,
    ctx: &mut LifeCycleCtx,
    event: &LifeCycle,
    data: &T,
    env: &Env

Handle a life cycle notification.

This method is called to notify your widget of certain special events, (available in the LifeCycle enum) that are generally related to changes in the widget graph or in the state of your specific widget.

A widget is not expected to mutate the application state in response to these events, but only to update its own internal state as required; if a widget needs to mutate data, it can submit a Command that will be executed at the next opportunity.

fn update(&mut self, ctx: &mut UpdateCtx, old_data: &T, data: &T, env: &Env)

Handle a change of data.

This method is called whenever the data changes. When the appearance of the widget depends on data, call request_paint so that it's scheduled for repaint.

The previous value of the data is provided in case the widget wants to compute a fine-grained delta.

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

Compute layout.

A leaf widget should determine its size (subject to the provided constraints) and return it.

A container widget will recursively call WidgetPod::layout on its child widgets, providing each of them an appropriate box constraint, compute layout, then call set_layout_rect on each of its children. Finally, it should return the size of the container. The container can recurse in any order, which can be helpful to, for example, compute the size of non-flex widgets first, to determine the amount of space available for the flex widgets.

For efficiency, a container should only invoke layout of a child widget once, though there is nothing enforcing this.

The layout strategy is strongly inspired by Flutter.

fn paint(&mut self, ctx: &mut PaintCtx, data: &T, env: &Env)

Paint the widget appearance.

The PaintCtx derefs to something that implements the RenderContext trait, which exposes various methods that the widget can use to paint its appearance.

Container widgets can paint a background before recursing to their children, or annotations (for example, scrollbars) by painting afterwards. In addition, they can apply masks and transforms on the render context, which is especially useful for scrolling.

Loading content...

Implementations on Foreign Types

impl<T> Widget<T> for Box<dyn Widget<T>>[src]

Loading content...


impl Widget<bool> for Checkbox[src]

impl Widget<bool> for Switch[src]

impl Widget<f64> for ProgressBar[src]

impl Widget<f64> for Slider[src]

impl Widget<f64> for Stepper[src]

impl Widget<String> for TextBox[src]

impl<C: Data, T: ListIter<C>> Widget<T> for List<C>[src]

impl<T, U, L, W> Widget<T> for LensWrap<U, L, W> where
    T: Data,
    U: Data,
    L: Lens<T, U>,
    W: Widget<U>, 

impl<T, W: Widget<T>, C: Controller<T, W>> Widget<T> for ControllerHost<W, C>[src]

impl<T: Data + PartialEq> Widget<T> for Radio<T>[src]

impl<T: Data> Widget<T> for Align<T>[src]

impl<T: Data> Widget<T> for Button<T>[src]

impl<T: Data> Widget<T> for Container<T>[src]

impl<T: Data> Widget<T> for Either<T>[src]

impl<T: Data> Widget<T> for Flex<T>[src]

impl<T: Data> Widget<T> for Label<T>[src]

impl<T: Data> Widget<T> for Padding<T>[src]

impl<T: Data> Widget<T> for Painter<T>[src]

impl<T: Data> Widget<T> for SizedBox<T>[src]

impl<T: Data> Widget<T> for Spinner[src]

impl<T: Data> Widget<T> for Split<T>[src]

impl<T: Data, U: PartialEq> Widget<T> for ViewSwitcher<T, U>[src]

impl<T: Data, W: Widget<T>> Widget<T> for EnvScope<T, W>[src]

impl<T: Data, W: Widget<T>> Widget<T> for IdentityWrapper<W>[src]

impl<T: Data, W: Widget<T>> Widget<T> for Scroll<T, W>[src]

impl<T: FromStr + Display + Data, W: Widget<String>> Widget<Option<T>> for Parse<W>[src]

Loading content...