anchors 6/n: Start splitting slivers! #1468
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…bottom This `i == 1` condition was never true, because in that situation the caller would build a MarkAsReadWidget instead of calling this method. This 8px vs. 11px distinction dates back to the prototype: 731b199 made it 8px instead of 0px, and the distinction itself goes back to the commit 9916194 msglist: Start on rendering messages in the prototype's first hours. The logic that drove it, though, became fragile with e7fe06c which changed it from "i == 0" (the end of the list, OK that's fairly canonical as a special value) to "i == 1" (more arbitrary). So then it naturally got broken a little later, in 56ab395 in 2023-11, and it's been broken ever since: we just always show 11px of padding here. We might further change the layout in the future, but if we do we'll fix it forward starting from the behavior the app has already had for over a year.
…ream Some of the behavior we'd like to customize isn't currently cleanly exposed to subclasses any more than it is to parent widgets passing constructor arguments. In particular, we'll want to change a few bits of logic in [RenderViewport.performLayout], replacing the handling of the `anchor` field with something more flexible. In order to do that, we'll start from a copy of that method, so that we can edit the copy. Then the base class's `performLayout` refers to a private helper method `_attemptLayout`, so we need a copy of that too; and they each refer to a number of private fields, so we need copies of those too; and to make those work correctly, we need copies of all the other members that refer to those fields, so that they're all referring correctly to the same version of those fields (namely the one on the subclass) rather than to a mix of the versions on the base class and those on the subclass. Fortunately, flood-filling that graph of members which refer to private members, which are referred to by other members, etc., terminates with a connected component which is... not small, but a lot smaller and less unwieldy than if we had to copy the whole upstream file these are defined in.
We'll rely on this assumption to simplify some upcoming customizations.
This is NFC as to the real message list, because so far the bottom sliver there always has height 0, so that maxScrollExtent is always 0. This is a step toward letting us move part of the message list into the bottom sliver, because it means that doing so would preserve the list's current behavior of starting out scrolled to the end.
This is NFC as to the real message list, because so far the bottom sliver there always has height 0. Before this change, the user could always scroll up (moving the content down) so that the bottom sliver was entirely off the bottom of the viewport, even if that exposed blank space at the top of the viewport because the top sliver was shorter than the viewport. After this change, it's never in bounds to have part of the viewport be blank for lack of content while there's content scrolled out of the viewport at the other end. This is a step toward letting us move part of the message list into the bottom sliver, because it fixes a bug that would otherwise create in the case where the top sliver fits entirely on the screen.
This is NFC as to the real message list, because so far the bottom sliver there always has height 0, so that both maxScrollExtent and this.maxScrollExtent are always 0. This is a step toward letting us move part of the message list into the bottom sliver, because it means that doing so would preserve the list's current behavior of remaining scrolled to the end once there as e.g. new messages arrive.
…-to-end show, act; TODO weaken test on crossing slivers Thanks to all the preparatory changes we've made in this commit series and those that came before it, this change should have only subtle effects on user-visible behavior. In particular: * The sticky headers should behave exactly as they did before, even when the sliver boundary lies under the sticky header, thanks to several previous commit series. * On first loading a given message list, it should start out scrolled to the end, just as before. * When already scrolled to the end, the message list should stay there when a new message arrives, or a message is edited, etc., even if the (new) latest message is taller than it was. Subtle differences include: * When scrolled up from the bottom and a new message comes in, the behavior is slightly different from before. The current exact behavior is something we probably want to change anyway, and I think the new behavior isn't particularly better or worse. * The behavior upon overscroll might be slightly different; I'm not sure. This therefore serves as a testing ground for all the ways that the message list's scrolling behavior can become more complicated when two (nontrivial) slivers are involved. If we find a situation where the behavior does change noticeably, that will be something to investigate and fix.
This makes our first payoff in actual UX from having the message list split into two back-to-back slivers! With this change, if you open a message list and the latest message is very tall, the list starts out scrolled so that you can see the top of that latest message -- plus a bit of context above it (25% of the viewport's height). Previously the list would always start out scrolled to the end, so you'd have to scroll up in order to read even the one latest message from the beginning. In addition to a small UX improvement now, this makes a preview of behavior we'll want to have when the bottom sliver starts at the first unread message, and may have many messages after that. This new behavior is nice already with one message, if the message happens to be very tall; but it'll become critical when the bottom sliver is routinely many screenfuls tall.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the next round after #1436 (and is stacked atop it), toward #82.
This is a draft because there's one remaining user-visible bug: the scroll-to-end button goes to a point above the end. I'm posting the draft because it's useful for manually testing the changes in #1436, by making them apply in the real Zulip message list.
In this PR:
(I'll make some changes to the scroll-to-end button. This PR is a draft because those aren't written yet.)
We start actually splitting the message list into back-to-back slivers, with the latest message in the bottom message list. Thanks to all the prep work up to this point, this change has only subtle effects in the UX.
The last commit takes advantage of the back-to-back slivers to make one nice, though small, UX improvement: when opening a message list where the latest message doesn't fit on the screen or nearly doesn't, we make sure to show the top of that latest message instead of the bottom.
In the future when the bottom sliver represents the unread messages, or the messages starting at another target anchor (anchor in the Zulip sense, not the
ScrollViewsense), this change will become much more important: we'll need to show the top of that potentially very tall bottom sliver, not its bottom.Selected commit messages
26d2d3a WIP msglist: Split into back-to-back slivers; TODO test?; TODO scroll-to-end show, act; TODO weaken test on crossing slivers
Thanks to all the preparatory changes we've made in this commit
series and those that came before it, this change should have only
subtle effects on user-visible behavior.
In particular:
The sticky headers should behave exactly as they did before,
even when the sliver boundary lies under the sticky header,
thanks to several previous commit series.
On first loading a given message list, it should start out
scrolled to the end, just as before.
When already scrolled to the end, the message list should stay
there when a new message arrives, or a message is edited, etc.,
even if the (new) latest message is taller than it was.
Subtle differences include:
When scrolled up from the bottom and a new message comes in,
the behavior is slightly different from before. The current
exact behavior is something we probably want to change anyway,
and I think the new behavior isn't particularly better or worse.
The behavior upon overscroll might be slightly different;
I'm not sure.
This therefore serves as a testing ground for all the ways that the
message list's scrolling behavior can become more complicated when
two (nontrivial) slivers are involved. If we find a situation
where the behavior does change noticeably, that will be something
to investigate and fix.
6e03b9e scroll: Show start of latest message if long, instead of end
This makes our first payoff in actual UX from having the message list
split into two back-to-back slivers!
With this change, if you open a message list and the latest message
is very tall, the list starts out scrolled so that you can see the
top of that latest message -- plus a bit of context above it (25% of
the viewport's height). Previously the list would always start out
scrolled to the end, so you'd have to scroll up in order to read
even the one latest message from the beginning.
In addition to a small UX improvement now, this makes a preview of
behavior we'll want to have when the bottom sliver starts at the
first unread message, and may have many messages after that.
This new behavior is nice already with one message, if the message
happens to be very tall; but it'll become critical when the bottom
sliver is routinely many screenfuls tall.