You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to be able to keep the next item in a list visible when scrolling through a list bigger than the viewable area to make large lists of items more understandable and pleasant to browse through.
Solution
Ideally the item before and after the currently selected item would remain visible while scrolling either up or down.
Or as many items before and after as the api user selects.
We can store a padding value in the ListState struct and have that passed through to the bounds checking that the List performs.
If we add serde(default) to the parameter in ListState we can avoid breaking changes from serialization.
Using this new feature would be the same as existing code for manually setting the offset, so any of the following:
*state.padding_mut() = 1;
state = state.with_padding(1);
state = ListState::default().with_padding(1);
By default padding would be disabled and would have no impact on existing users without any action on their end.
I've developed an existing fork that has this feature working and tested. I've so far been using the name "padding" but I think "scroll_padding" would be much less ambiguous and confusing. I'm open to suggestions.
I've attached gif(s) of current and desired behavior bellow.
Alternatives
Alternatively, I could just handle this myself in the api user side of the code. But it would be very difficult to handle items of inconsistent sizes without reimplementing much of the existing bounds checking code in List rendering.
Additionally doing it that way could leave that user side code vulnerable to otherwise non-breaking changes that adjust how lists are rendered. Like the existing PR for adding what I'd probably describe as list item padding.
Additional context
Current behavior:
Desired behavior:
The text was updated successfully, but these errors were encountered:
I think this is a good idea user-wise.
Code-wise I'd accept if this is not overly complex, which it seems for now. But I'm sure there is room for improvement.
I'd recommend submitting a PR and we can discuss there.
Introduces scroll padding, which allows the api user to request that a certain number of ListItems be kept visible above and below the currently selected item while scrolling.
```rust
let list = List::new(items).scroll_padding(1);
```
Fixes: #955
Problem
I would like to be able to keep the next item in a list visible when scrolling through a list bigger than the viewable area to make large lists of items more understandable and pleasant to browse through.
Solution
Ideally the item before and after the currently selected item would remain visible while scrolling either up or down.
Or as many items before and after as the api user selects.
We can store a padding value in the ListState struct and have that passed through to the bounds checking that the List performs.
If we add serde(default) to the parameter in ListState we can avoid breaking changes from serialization.
Using this new feature would be the same as existing code for manually setting the offset, so any of the following:
By default padding would be disabled and would have no impact on existing users without any action on their end.
I've developed an existing fork that has this feature working and tested. I've so far been using the name "padding" but I think "scroll_padding" would be much less ambiguous and confusing. I'm open to suggestions.
I've attached gif(s) of current and desired behavior bellow.
Alternatives
Alternatively, I could just handle this myself in the api user side of the code. But it would be very difficult to handle items of inconsistent sizes without reimplementing much of the existing bounds checking code in List rendering.
Additionally doing it that way could leave that user side code vulnerable to otherwise non-breaking changes that adjust how lists are rendered. Like the existing PR for adding what I'd probably describe as list item padding.
Additional context
Current behavior:
Desired behavior:
The text was updated successfully, but these errors were encountered: