-
Notifications
You must be signed in to change notification settings - Fork 115
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
First cut at Widget trait #26
Conversation
This is an attempt to define the Widget trait. It compiles and runs but is a bit incomplete: * The HotChanged propagation has not been ported. * It is missing accessibility methods. * No doubt some cleanup is still needed.
/// the provided [`UpdateCtx`] to schedule calls to [`paint`] and [`layout`] | ||
/// as required. | ||
/// | ||
/// This method may go around. |
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.
"May go around"? Is this saying that the method may go away in future, like the original comment suggested, or something else?
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 meant "may go away" and typo'ed it. That said, my current thinking is to retain it, and I am also considering plumbing the AccessKit node update mechanism through the method. That will require some more careful design.
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 was expecting the accessibility stuff to be handled more like painting with a separate ChangeFlag
, phase and trait method. I have not yet looked at AccessKit's API however.
Using update
as a kind of environment change event could be a good idea.
/// the direction in which they grow as their number of children increases. | ||
/// Has some methods for manipulating geometry with respect to the axis. | ||
#[derive(Debug, Clone, Copy, PartialEq, Eq)] | ||
pub enum Axis { |
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.
Are these axes directional? I.e. does Vertical
imply an origin at the top (or bottom) of the visual space, or is that direction independent of this?
pub fn shrink_max_height_to(&self, dim: f64) -> Self { | ||
let mut max = self.max(); | ||
max.height = f64::max(dim, self.min().height); | ||
BoxConstraints::new(self.min(), max) |
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 there also be something like f64::min(dim, max.height)
in here, to keep from increasing the max?
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.
This (along with Axis
) is copied without change from Druid. Not that there's no chance of flaws there, but it's not something I'm focusing on at the moment.
Turn on the AccessKit dependency and also update to more recent glazier and Vello versions.
This is a first cut at AccessKit integration. The intent is to get the signatures correct in the `Widget` trait, and demonstrate basic functionality (clicking a button), but there is much to be done before it can be considered complete.
At present, leaf widgets do need to check that the target id matches. Possibly we will relax that if we get precise child tracking, which would guarantee that an event won't be propagated unless the subtree contains the target.
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.
There are some things we could change but i think it works the way it is now. Therefore i am in favor of merging it as soon as possible and create followup PRs with small changes instead of making this PR perfect.
/// This does not mean the value returned by layout() would be the same. | ||
/// | ||
/// This method **must** return a finite value. | ||
fn compute_max_intrinsic( |
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 we should either add a compute_max_intrinsic
method to Pod
or remove 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.
I agree, and I also think that should happen in a followup PR. The scope of this one is focused on the Widget
trait itself, and it's known that there's a bunch more wiring, especially in Pod
, that needs to be done.
src/widget/core.rs
Outdated
/// The minimum intrinsic size of the widget. | ||
pub(crate) min_size: Size, | ||
/// The maximum intrinsic size of the widget. | ||
pub(crate) max_size: Size, |
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.
The values of min_size
and max_size
are never changed. Are they remains of the exploration of SwiftUI
layout?
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 will remove them, thanks for the heads-up.
src/widget/contexts.rs
Outdated
@@ -146,40 +155,51 @@ impl<'a, 'b> LayoutCx<'a, 'b> { | |||
} | |||
} | |||
|
|||
pub fn add_event(&mut self, event: Event) { | |||
pub fn add_event(&mut self, event: Message) { |
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.
We should probably rename this and similar methods.
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.
Will do. However, looking at this now, I'm concerned I've introduced a layering violation; Message
is a Xilem type, and that might make it harder to integrate other reactive layers. I'll file an issue on this.
Remove some vestiges of old layout system. Make rename of View-level event to "message" more consistent.
Thanks for the review! Apparently the way we've got the repo set up, it needs another approval after a new commit, which honestly feels a bit restrictive. I'll self-approve and merge if there's no activity soon. |
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've not reviewed; signing off since @xarvic 's review isn't sufficient for GitHub's approval
I had a look at the settings, and it looks like you can push new commits and the approval will remain. Has someone changed the settings recently, perhaps? |
We worked it out on Zulip |
This is an attempt to define the Widget trait. It compiles and runs but is a bit incomplete:
This is work toward #7