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
Comment by Hixie Saturday Aug 22, 2015 at 17:17 GMT
I think the right API here is to just change the "direction" argument to take four values instead of two. Instead of horizontal/vertical, have it be right (what we do now for horizontal)/down (what we do now for vertical)/left (horizontal with reverse gravity)/up (vertical with reverse gravity).
Comment by abarth Saturday Aug 22, 2015 at 17:46 GMT
Would you change the semantics of scrollOffset also? For example, in the up direction, would offset zero correspond to the last item in the scrollable list being visible? For example, [A, B, C, D, E, F, G], direction: up, scrollOffset: 0
-
C
D
E
F
G
-
Presumably we shouldn't reverse the order of the list, so [A, B, C], direction: up would display as:
Comment by abarth Saturday Aug 22, 2015 at 18:01 GMT
That makes a certain amount of sense, but it would not solve @apwilson 's problem. Maybe that means we should solve his problem in a different way. Here's the effect that @apwilson wants:
Start out with a list [A, B, C, D, E, F, G, H, I, J]
-
D
E
F
G
H
-
Now, he wants to remove E from the list and end up with:
-
C
D
F
G
H
-
Now, he wants to remove D from the list and end up with:
-
C
F
G
H
I
-
In other words, he doesn't want the order of the list to change visually, he just wants to control whether new items are pulled into the viewport from the top or the bottom when the content size decreases.
Comment by Hixie Saturday Aug 22, 2015 at 20:56 GMT
That seems equivalent to reversing the list and using "direction:up", then, no? Or is the requirement really that different removals back to back cause the list to collapse in different directions?
Comment by abarth Saturday Aug 22, 2015 at 21:17 GMT
That seems equivalent to reversing the list and using "direction:up", then, no?
Yes.
Or is the requirement really that different removals back to back cause the list to collapse in different directions?
The same list needs to exhibit both collapsing directions at different times (but not at the same time). It might be easier to show you what @apwilson is building than to work this all out via bugthread.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
FlutterIssues commentedon Nov 9, 2015
Saturday Aug 22, 2015 at 17:17 GMT
I think the right API here is to just change the "direction" argument to take four values instead of two. Instead of horizontal/vertical, have it be right (what we do now for horizontal)/down (what we do now for vertical)/left (horizontal with reverse gravity)/up (vertical with reverse gravity).
FlutterIssues commentedon Nov 9, 2015
Saturday Aug 22, 2015 at 17:46 GMT
Would you change the semantics of scrollOffset also? For example, in the
updirection, would offset zero correspond to the last item in the scrollable list being visible? For example, [A, B, C, D, E, F, G], direction: up, scrollOffset: 0Presumably we shouldn't reverse the order of the list, so [A, B, C], direction: up would display as:
Rather than:
FlutterIssues commentedon Nov 9, 2015
Saturday Aug 22, 2015 at 17:49 GMT
I imagined that [A, B, C, D, E, F, G], direction: up, scrollOffset: 0 would render as:
FlutterIssues commentedon Nov 9, 2015
Saturday Aug 22, 2015 at 18:01 GMT
That makes a certain amount of sense, but it would not solve @apwilson 's problem. Maybe that means we should solve his problem in a different way. Here's the effect that @apwilson wants:
Start out with a list [A, B, C, D, E, F, G, H, I, J]
Now, he wants to remove E from the list and end up with:
Now, he wants to remove D from the list and end up with:
In other words, he doesn't want the order of the list to change visually, he just wants to control whether new items are pulled into the viewport from the top or the bottom when the content size decreases.
FlutterIssues commentedon Nov 9, 2015
Saturday Aug 22, 2015 at 18:49 GMT
I'm assuming based on our IRC conversation that when removing E and removing D, the gravities are configured differently.
What should happen when the list has only 5 items and one is removed in the reverse-gravity case?
FlutterIssues commentedon Nov 9, 2015
Saturday Aug 22, 2015 at 20:20 GMT
I would expect empty space to appear from the top.
FlutterIssues commentedon Nov 9, 2015
Saturday Aug 22, 2015 at 20:56 GMT
That seems equivalent to reversing the list and using "direction:up", then, no? Or is the requirement really that different removals back to back cause the list to collapse in different directions?
FlutterIssues commentedon Nov 9, 2015
Saturday Aug 22, 2015 at 21:17 GMT
Yes.
The same list needs to exhibit both collapsing directions at different times (but not at the same time). It might be easier to show you what @apwilson is building than to work this all out via bugthread.
3 remaining items
abarth commentedon Feb 9, 2016
Warming up in #1710
Add scroll anchor for Block
Use -nostdinc++ on Android since those headers need to be picked up f…
Revert "Remove ldflag no longer necessary with the new toolchain. (fl…
github-actions commentedon Sep 6, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.