Add hot glow option to multiwin example.#845
Conversation
luleyleo
left a comment
luleyleo
left a comment
There was a problem hiding this comment.
Now I've got another GTK issue to work on, the MouseLeave event seems to work only when leaving very slowly 🤔 I've two nit picks tho.
Thanks for the example!
druid/examples/multiwin.rs
Outdated
| if matches!(event, LifeCycle::HotChanged(_)) { | ||
| ctx.request_paint(); | ||
| } |
There was a problem hiding this comment.
For consistency with other examples
| if matches!(event, LifeCycle::HotChanged(_)) { | |
| ctx.request_paint(); | |
| } | |
| if let LifeCycle::HotChanged(_) = event { | |
| ctx.request_paint(); | |
| } |
druid/examples/multiwin.rs
Outdated
| ) -> Size { | ||
| let size = self.inner.layout(ctx, bc, data, env); | ||
| self.inner.set_layout_rect(size.to_rect()); | ||
| bc.max() |
There was a problem hiding this comment.
Returning size would make this container 'neutral' regarding layout, which seems more idiomatic to me
| bc.max() | |
| size |
There was a problem hiding this comment.
Probably better with size indeed.
cmyr
left a comment
cmyr
left a comment
There was a problem hiding this comment.
just some notes that occur to me while looking over this, no changes needed
| inner: WidgetPod<State, W>, | ||
| } | ||
|
|
||
| impl<W: Widget<State>> Glow<W> { |
There was a problem hiding this comment.
just a note: I think you could have achieved this using a Painter?
There was a problem hiding this comment.
Perhaps in some way, but it wasn't super obvious. Like the Painter docs state: If you would like it to repaint at other times (such as when hot or active state changes) you will need to call request_paint further up the tree. There's nothing further up the tree, so it wouldn't just be a Painter at least.
There was a problem hiding this comment.
oh huh for some reason I thought it did repaint on hot. My mistake!
I wonder if it makes sense to just make 'paint on hot' be an option for painter? but that's a small thing.
| } | ||
|
|
||
| struct Glow<W> { | ||
| inner: WidgetPod<State, W>, |
There was a problem hiding this comment.
if a widget is entirely transparent for the purposes of event handling and layout (it is just passing things through) then WidgetPod is unnecessary. It doesn't hurt in any meaningful way, but it is unnecessary.
There was a problem hiding this comment.
This really needs to be written down 😅
| ) -> Size { | ||
| let size = self.inner.layout(ctx, bc, data, env); | ||
| self.inner.set_layout_rect(ctx, data, env, size.to_rect()); | ||
| size |
There was a problem hiding this comment.
a general note; I think it's good to call bc.constrain(size) anytime you return from layout, as a way of ensuring all returned sizes are appropriate for the constraints.
There was a problem hiding this comment.
Well, my inspiration came from ControllerHost which does not do that, maybe open an Issue to make this consistent for all container?
3 participants
This PR adds an option to the context menu of the multiwin example. When enabled the background turns red when the window is hot.
I've used it successfully to test the workings of hot state and I think it can be interesting to others as well. Also it will be useful for demonstrating various hot state issues that I plan to tackle in upcoming PRs.