-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement TaffyLayout
widget
#140
Conversation
3c0edfd
to
7eae31b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to reduce the redundancy between layout and compute_max_intrinsic?
Seems like a good start to get stuff moving. The cache will be very important in the future.
6a6ff39
to
07372b7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works great! Really looking forward to have this merged!
I will finally get around to reviewing this today!
Is this something that will be in a separate PR? @nicoburns |
fbc74c0
to
196ee30
Compare
I had a quick think about how this might be implemented, and I think it will need to be. Adding the cache is relatively straightforward. The thing I am currently blocked on is cache invalidation. If the styles of a view/widget change, then the cache would need to be invalidated for that widget and all parents. And I'm not currently sure how to do that? (perhaps a message / event - but how does one send one of those?). It would also be possible to forgo caching between multiple layout runs (and only have it within a single run) and somehow have a "prelayout" or "postlayout" event in which we drop the caches. |
196ee30
to
c61936c
Compare
39ccbbb
to
33e03c1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be mostly happy to land this if the taffy feature were added.
I think it would be fine as not optional, but in that case a few things need to be addressed
src/widget/button.rs
Outdated
@@ -108,6 +108,7 @@ impl Widget for Button { | |||
); | |||
self.layout = Some(layout); | |||
//(Size::new(10.0, min_height), size) | |||
cx.request_paint(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be automatic/implied?
If the widget is being re-layed out, it seems surprising that it would ever want to not be repainted.
I guess the case would be if it hasn't resized. But in that case, should we be resizing here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly... I was calling it unconditionally, but now that I've added layout caching it actually doesn't get called if there is a cache hit. I'm not sure whether this would ever save a meaningful amount of work.
} | ||
|
||
/// creates a horizontal [`TaffyLayout`]. | ||
pub fn div<T, A, VT: ViewSequence<T, A>>(children: VT) -> TaffyLayout<T, A, VT> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Div isn't a very compelling name. If there's an alternative you can think of, I'd like to change to it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... it's called div
because that's the name on web, and I can't think of why you'd want to use block layout unless you're emulating web. I could just remove it entirely? Or call it something like raw_taffy_layout
?
33e03c1
to
63fe0dd
Compare
Some basic caching is now implemented. It really ought to be implemented for the |
d9ee16f
to
fde5adb
Compare
Implement compute_max_intrinsic for Box<dyn AnyWidget>
fde5adb
to
b280f83
Compare
Not easily. As things stand you could combine them into one method with a parameter instead. But I would expect these methods to further diverge over time, and IMO this would already be more confusing than a small amount of duplication. |
b280f83
to
9dccf90
Compare
I believe I've addressed all of the review feedback, so this is ready for re-review. I've also made #146 independent of this PR if anybody has time to review that (which is hopefully a little less controversial than this one). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fab. Sorry no-one has reviewed until now.
Objective
Enable Taffy based layout to be used with Xilem
Changes made
compute_max_intrinsic
method toPod
(this method already existed on theWidget
trait)downcast_ref
method toPod
(there was already adowncast_mut
method)cx.request_paint()
in the layout method of the button widget (otherwise it wasn't repainting on window resize)TaffyLayout
widget and corresponding view (adapted from theLinearLayout
). Constructors for the view currently includeflex_row
,flex_column
, anddiv
.taffy
example which uses the new view/widget.Notes
This is currently depending on it's own branch of Taffy. But the changes are relatively minor (making Taffy pass along which Axis it is measuring when requesting child measurement), and I don't anticipate major issues getting them merged. (Pass axis information when measuring a child's size DioxusLabs/taffy#575)Changes now merged to Taffy'smain
branch. I would anticipate a few further minor changes, but the integration works as-is.taffy::style::Style
on each widget. But it would possible to create more specialised widgets to reduce memory overhead.Screenshot