Rewrite tutorial #813
Rewrite tutorial #813
Conversation
| @@ -130,9 +75,10 @@ impl ColorRectangle { | |||
| ``` | |||
|
|
|||
| This widget doesn't have children and doesn't really need to keep track of any transient state, so its definition is pretty simple. | |||
| Note that we store a size, and not a position: our widget's position is picked by its parent. | |||
| Note that we store a size, and not a position: our widget's position is tracked by its parent. | |||
There was a problem hiding this comment.
controlled or managed? Masonry itself does the "tracking"
| @@ -244,7 +202,7 @@ impl Widget for ColorRectangle { | |||
|
|
|||
| In our `paint` method, we're given a [`vello::Scene`] and paint a rectangle into it. | |||
|
|
|||
| The rectangle's position is zero (because coordinates in our scenes are local to our widget), and its size is `ctx.size()`, which is the value returned by `layout()`; though we could also have used `self.size`. | |||
| The rectangle's position is zero (because coordinates in our scene are local to our widget), and its size is `ctx.size()`, which is the value returned by `layout()`; though we could also have used `self.size`. | |||
There was a problem hiding this comment.
Maybe origin instead of "position"?
| @@ -244,7 +202,7 @@ impl Widget for ColorRectangle { | |||
|
|
|||
| In our `paint` method, we're given a [`vello::Scene`] and paint a rectangle into it. | |||
|
|
|||
| The rectangle's position is zero (because coordinates in our scenes are local to our widget), and its size is `ctx.size()`, which is the value returned by `layout()`; though we could also have used `self.size`. | |||
| The rectangle's position is zero (because coordinates in our scene are local to our widget), and its size is `ctx.size()`, which is the value returned by `layout()`; though we could also have used `self.size`. | |||
There was a problem hiding this comment.
I don't really like "though we could also have used self.size." here - it is true, but it's only true because we have an over-eager layout implementation.
My suggestion would be to change layout to use bc.contrain(self.size), then we can remove this aside.
There was a problem hiding this comment.
My suggestion would be to change layout to use
bc.contrain(self.size)
Hard disagree.
This is probably something that should be documented (actually, I'm surprised we don't already), but my model of our layout algorithm is that, in some cases, some widgets will return a size that's outside of the constraints their parent gave them and the parent widget needs to deal with it without visual bugs.
EDIT: Wait, I misunderstood what you wrote. You meant changing the implementation of ColorRectangle::layout().
I guess that makes sense, though it needs a longer explanation.
| } | ||
| ``` | ||
|
|
||
| Then, we update our paint method: |
There was a problem hiding this comment.
I'd consider swapping these two code blocks, as it lets us explain request_paint_only. Alternatively, we should just use request_render to not over-complicate things with accessibility.
| Instead, there are two ways to mutate `Label`: | ||
|
|
||
| - Inside a Widget method. Most methods (`on_pointer_event`, `update`, `layout`, etc) take a `&mut self` argument. | ||
| - Through a [`WidgetMut`] wrapper. So, to change your label's text, you will call `WidgetMut::<Label>::set_text()`. This helps Masonry make sure that internal metadata is propagated after every widget change. |
There was a problem hiding this comment.
And you could change that to an intra-doc link to make sure it stays up to date through any renames.
Rewrite "Creating a new Widget" tutorial to interleave description of the Widget trait with example.
Go into more details.
Rewrite tutorials to use current WidgetMut syntax (the one with free functions instead of methods).