Skip to content
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

Merged
merged 7 commits into from
Jan 21, 2023
Merged

First cut at Widget trait #26

merged 7 commits into from
Jan 21, 2023

Conversation

raphlinus
Copy link
Contributor

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.

This is work toward #7

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.
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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 {
Copy link
Contributor

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?

Comment on lines +316 to +319
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)

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?

Copy link
Contributor Author

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.
@raphlinus raphlinus marked this pull request as ready for review January 18, 2023 04:33
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.
Copy link
Collaborator

@xarvic xarvic left a 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(
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Comment on lines 81 to 84
/// The minimum intrinsic size of the widget.
pub(crate) min_size: Size,
/// The maximum intrinsic size of the widget.
pub(crate) max_size: Size,
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

@@ -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) {
Copy link
Collaborator

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.

Copy link
Contributor Author

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.
@raphlinus
Copy link
Contributor Author

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.

Copy link
Member

@DJMcNab DJMcNab left a 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

@raphlinus raphlinus merged commit d84812a into main Jan 21, 2023
@raphlinus raphlinus deleted the widget branch January 21, 2023 20:36
@raphlinus raphlinus mentioned this pull request Jan 21, 2023
@richard-uk1
Copy link
Contributor

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?

@DJMcNab
Copy link
Member

DJMcNab commented Jan 22, 2023

We worked it out on Zulip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants