-
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
Scrolling changes and small other fixes to support druid_table #1108
Conversation
…o for now). Mainly around synchronising the scrolling of sibling components and being able to issue commands from a few more places.
So configuration parameters can be propagated through the widget hierarchy
…n repo for now). This is to allow disabling scrollbar visibility in the Scroll widget
I like this apart from the fact that of course I'm going to want #1107 merged in and this rebased on that :) The ability to disable scrollbars is definitely needed and a command to ask a scroll to scroll to a position is very helpful for the 95% of time where composition suits the situation. Adding clone to The CI failing is identical to what is on the aforementioned PR so it doesn't seem to be Github Actions bugging out like we've had in the past so we should probably figure out how we are depending on |
I still think 1107 needs splitting up into multiple stages (list changes, behaviour split inside the scroll file, and then gratuitous moves/renames), and this shouldn’t be blocked by it. |
or it doesn't get a WidgetAdded.
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 left a few comments. If you're willing to split out the easy parts (i.e. env.rs
, contexts.rs
, view_switcher.rs
) then I can get them merged ASAP. For the scroll parts, I need to spend some more time with this and #1107 (also, secretly hoping that someone with more experience/authority/opinions than me will help in sorting out the conflicts...)
druid/src/contexts.rs
Outdated
|
||
pub fn submit_command(&mut self, cmd: impl Into<Command>, target: impl Into<Option<Target>>) { | ||
self.state.submit_command(cmd.into(), target.into()) | ||
} |
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've started using macros to implement methods for multiple contexts. We don't seem to have one yet for the intersection of Event/Update/LifeCycle/Layout, so you'll need a new impl_context_method!
block.
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 noticed that too late! Can look into it
druid/src/contexts.rs
Outdated
@@ -633,7 +641,7 @@ impl<'a> ContextState<'a> { | |||
} | |||
} | |||
|
|||
fn submit_command(&mut self, command: Command, target: Option<Target>) { | |||
pub(crate) fn submit_command(&mut self, command: Command, target: Option<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.
Why this change? Don't we only call it from within the module?
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 I meant to revert this - can't remember why I changed it!
druid/src/widget/scroll.rs
Outdated
let mut offset = self.scroll_offset + delta; | ||
offset.x = offset.x.min(self.child_size.width - size.width).max(0.0); | ||
offset.y = offset.y.min(self.child_size.height - size.height).max(0.0); | ||
pub fn scroll(&mut self, ctx: &mut EventCtx, delta: Vec2, size: Size) -> bool { |
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.
Given that we have scroll_to
now, maybe scroll_by
would be a better name? Might not be worth the breaking change, though.
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 are right, I just didn't want to break anyone
druid/src/contexts.rs
Outdated
@@ -615,6 +619,10 @@ impl PaintCtx<'_, '_, '_> { | |||
transform: current_transform, | |||
}) | |||
} | |||
|
|||
pub fn viewport_offset(&self) -> Vec2 { |
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.
API docs?
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.
Can do. I will work out if I actually needed this in the end
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 didn't need it so its gone
druid/src/widget/scroll.rs
Outdated
)), | ||
); | ||
|
||
ctx.submit_command(SCROLL_TO.with(scroll_to), ctx.widget_state.id); |
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.
When you submit a command in layout
or lifecycle
, it won't be processed until (at least) the next frame. I think scrolling immediately is better.
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 was because the scroll callback takes an EventContext (so they can submit commands). I think I may have experimented with giving them the ContextState (and thats why I changed the visibility on that method)? Or something wrapped around it. Maybe need their own context that is minimal and just lets them do what we expect, that can be derived from any other context...
let mut offset = self.scroll_offset + delta; | ||
offset.x = offset.x.min(self.child_size.width - size.width).max(0.0); | ||
offset.y = offset.y.min(self.child_size.height - size.height).max(0.0); | ||
pub fn scroll_by(&mut self, submit: &mut SubmitCommand, delta: Vec2, size: Size) -> bool { |
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 see you've decided to go for the breaking change. Which is fine, but it (along with the other publicly-visible changes in this PR) will need a CHANGELOG entry...
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.
Ok. My thoughts were that the signature had changed so much, may as well break the name.
It already was slightly odd, due to the size, which was obtained from a context from the scrolls own widget pod - calling it from outside meant doing tricks to obtain that. So it was never great as public api - what would be needed for that is “scroll here when you can”, ie a pending scroll - but this is recreating the command system afaict. I’m going to make an alternate PR, based on the binding/scope stuff I mentioned on Zulip. It’s much closer to the composition you are talking about above, and there aren’t any callbacks. Then people can pick between approaches.
Not much point in this if I'm going to drip feed in bits from binding scroll. |
Druid_table is at https://github.com/rjwittams/druid_table/ for now and has been discussed on Zulip.
I had to make some small changes to druid to get things working (synchronising the sibling widgets).