-
Notifications
You must be signed in to change notification settings - Fork 237
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
Open a message list in the middle of history, when requested #82
Labels
a-msglist
The message-list screen, except what's label:a-content
Milestone
Comments
gnprice
added
the
a-msglist
The message-list screen, except what's label:a-content
label
May 27, 2023
gnprice
added a commit
that referenced
this issue
Jun 14, 2023
gnprice
added a commit
to gnprice/zulip-flutter
that referenced
this issue
Jan 30, 2024
This means that the overall scroll view has AxisDirection.down as the scroll direction, rather than AxisDirection.up, and the SliverStickyHeader is passed GrowthDirection.reverse instead of GrowthDirection.forward in order to get the same effect. This makes the scrolling a little easier to think about when focused on MessageList's code, because for example (as seen in this diff) `scrollMetrics.extentBefore` now refers to the messages that are older than the ones on screen, rather than those that are newer. This also brings us closer to the setup we'll want for zulip#80 and zulip#82, opening the message list at an anchor other than the end: the empty placeholder sliver at the bottom will become the list of messages after the starting anchor, while the sliver at the top will remain the list of messages above the anchor.
gnprice
added a commit
to gnprice/zulip-flutter
that referenced
this issue
Jan 30, 2024
This means that the overall scroll view has AxisDirection.down as the scroll direction, rather than AxisDirection.up, and the SliverStickyHeader is passed GrowthDirection.reverse instead of GrowthDirection.forward in order to get the same effect. This makes the scrolling a little easier to think about when focused on MessageList's code, because for example (as seen in this diff) `scrollMetrics.extentBefore` now refers to the messages that are older than the ones on screen, rather than those that are newer. This also brings us closer to the setup we'll want for zulip#80 and zulip#82, opening the message list at an anchor other than the end: the empty placeholder sliver at the bottom will become the list of messages after the starting anchor, while the sliver at the top will remain the list of messages above the anchor.
chrisbobbe
pushed a commit
that referenced
this issue
Jan 30, 2024
This means that the overall scroll view has AxisDirection.down as the scroll direction, rather than AxisDirection.up, and the SliverStickyHeader is passed GrowthDirection.reverse instead of GrowthDirection.forward in order to get the same effect. This makes the scrolling a little easier to think about when focused on MessageList's code, because for example (as seen in this diff) `scrollMetrics.extentBefore` now refers to the messages that are older than the ones on screen, rather than those that are newer. This also brings us closer to the setup we'll want for #80 and #82, opening the message list at an anchor other than the end: the empty placeholder sliver at the bottom will become the list of messages after the starting anchor, while the sliver at the top will remain the list of messages above the anchor.
This was referenced May 16, 2024
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the user takes an action that should navigate to a particular "anchor" message (like through #73 internal links, #76 deep links, or a notification), we should take them straight to that message, rather than to the latest message or first unread message in the narrow.
This is a feature the zulip-mobile RN app lacks: zulip/zulip-mobile#3604 . (That's for internal links, but the app doesn't have it for notifications either — see
narrowToNotification
which passes no anchor todoNarrow
— and doesn't have deep links.)There are two parts to this:
This has a lot in common with:
This issue has fewer prerequisites technically than #80 — no need for #79 first. On the other hand it has more prerequisites before there's a UX context where it makes sense: it'd need either #73, #76, or notifications, all of which are more complex than #79.
The text was updated successfully, but these errors were encountered: