Instead of the `paint` method returning a `Rendered` which was just a
newtype around `SceneFragment`, pass in `&mut SceneBuilder`. Also store
a scene fragment in each `Pod`, which is the storage for these builders.
This change has a number of consequences. Less boilerplate in the paint
method, and also less allocation, as the storage can get reused. More
importantly, though we don't have the logic for this yet, it sets the
stage for retaining scene fragments when widgets don't change.
This adds the rendering of the gradient to the button widget.
The "piet_scene_helpers" module is a bit hacky, we'll need to have some discussions about how to handle kurbo shape types more easily. But it should work for now.
We don't deny warnings in CI because we currently have warnings.
Once #1 lands, we can enforce cleanliness from warnings
See also d0b9e1905c
as we only use windows at the moment
This is a snapshot of the current state of the xilem prototype built on new infrastructure: glazier for window creation, piet-gpu for drawing, and parley for text.
As of this snapshot, only the text widget has been ported, and there are a number of rough edges. It should be considered a proof of concept. That said, it should be possible to build more from here.
Do in reverse order to prioritize what's likely to become visible. Expand range by 10. A more sophisticated approach is probably wanted eventually, but this simple tweak helps quite a bit.
Use timeout_at future rather than spawning a separate task to send a timeout message. This should also improve performance, as it's less likely that the task is starved.
This runs the app logic and event dispatch in a separate task.
There is some hackery in than the App abstraction spins up a tokio runtime and enters it during the UI runloop. Likely it would be better to let the client do this. But it seems to work, at least for this example.
Enforce Send for the View trait. Originally I wanted to move Widget across thread boundaries but that isn't going to work with current Piet.
Also makes the associated state Send.
But also note, this does *not* put a Send bound on T. Running the app logic and doing event propagation will be done on the view task. But we'll see what we bump into.
We were running into tokio's cooperative scheduling, see this bug:
https://github.com/tokio-rs/tokio/issues/2418
I'm sure there's some way to make that work, but in the meantime just switching to smol lets us make progress.
This is the demo I showed at the SF Rust meetup 2022-05-24.
This commit implements the core functionality of button, including hot/active states, drawing of appearance, and reasonable layout.
There are other changes in widget infrastructure to support this functionality.
Add the lifecycle method to the Widget trait, matching existing Druid. I'm not at all convinced it's necessary - in original Druid, one of the main differences is that it doesn't have mutable access to app state, but that concern isn't really relevant. In any case, this minimizes divergence, and can possibly be cleaned up later.
Import some of the event dispatching logic from Druid. Still fairly minimal, not yet doing real hot/active logic on buttons yet (doing it the same way as Druid would depend on adding lifecycle to the Widget trait).
Zoxc