Skip to content

Design new Widget trait #7

@raphlinus

Description

@raphlinus

An important step in building out the widget tree is to get the trait right. Further iteration is possible, but getting it basically right at this time will save hassle later.

The high-level approach is to start with the Druid Widget trait and make some changes.

  • The data argument goes away (as does being generic on T). This is a natural consequence of the Xilem architecture.

  • The env argument goes away, I think. This is actually a much bigger question, as we rely on env to retrieve style data, so probably deserves some thought about what will replace that.

  • The paint method evolves to generate a piet-gpu scene fragment rather than drawing into a Piet render context.

  • The trait also needs to update the accessibility tree. In the prototype Druid integration for AccessKit, there an accessibility() method that generates the node, but that's based on generating the entire tree every time rather than doing incremental update. This needs to be worked out in detail.

As discussed in today's office hours, we will not be making significant changes to layout at this time, so those methods will basically be the same as Druid's existing Flutter-like mechanism.

The update method

Right now the update method isn't doing much, and if #6 gets adopted, it will do even less. In current Druid, one of its other roles is to respond to env changes (if theme or styling changes), but that may well go away as well.

A potential role may be to update the accessibility tree, but likely that should be a separate method, as it should be lazy (only called when a screen reader is connected).

So one of the questions which needs to be decided is whether to keep the update method or remove it. An excellent way to help resolve it is to go through the existing use cases in Druid and see if any really motivate keeping it.

The lifecycle method

We can also consider combining lifecycle and event, as the motivation for having them separate may no longer be compelling. I consider this a lower priority, as I'm sure it's fine either way, but again if we do decide to change this from Druid, it would be less work to do it now than later.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions