-
Notifications
You must be signed in to change notification settings - Fork 567
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
Make Padding generic of child type and add child getters #1634
Conversation
druid/src/widget/padding.rs
Outdated
impl<T, W> Padding<T, W> { | ||
/// A reference to this widget's child. | ||
pub fn child(&self) -> &W { | ||
self.child.widget() | ||
} | ||
|
||
/// A mutable reference to this widget's child. | ||
pub fn child_mut(&mut self) -> &mut W { | ||
self.child.widget_mut() | ||
} | ||
} |
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 think you can use widget_wrapper_body
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.
mm, I'd completely forgotten about that. It looks like it's only implemented for types that don't contain a WidgetPod
? The intent when that was merged was just to facilitate robert's experiments with bindings (or maybe scope?) and I'm not sure if it makes sense as a general mechanism? (In particular it's hard to discover, and requires having the trait in scope).
Maybe @rjwittams can chime in.
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 looks like it's only implemented for types that don't contain a WidgetPod?
there is also widget_wrapper_pod_body
.
I'm not sure if it makes sense as a general mechanism?
I am not sure either but implementing a trait feels better to me.
In particular it's hard to discover, and requires having the trait in scope
I wish we had ability to mark trait as "important", so that rustdoc highlights 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.
Looks good! We can implement the WidgetWrapper
trait later if needed
Sorry missed this. WidgetWrapper was implemented for every 'widget type preserving' wrapper, ie those which don't dyn away the api of what they are wrapping. The reason I need it for bindings was to reach inside things like lenswrap and scope, because binding before the data change doesn't work, as the binding host needs to know about it. I doubt it is worth going into details of why here... I think the whole way we deal with data and leaf widgets etc is a bit broken at the moment (they should all be widgets of () and something like bindings should be used for their reactivity). But all that I expect is up for debate with arch changes etc. On the trait vs not trait thing. Dealing with trait imports just seems like the cost of doing business in Rust. Throwing out polymorphism to avoid imports seems like a very odd thing to even consider to me. |
And implement WidgetWrapper. This is another small thing I wanted for the textbox rework.
This is another small thing I wanted for the textbox rework.