-
Notifications
You must be signed in to change notification settings - Fork 309
msglist: Have content pad bottom inset when the compose box isn't shown #379
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
Conversation
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.
Thanks for this fix! This had been bugging me occasionally before the mark-as-read button, too.
Does #263 correspond to what this fixes?
One small code comment below.
lib/widgets/message_list.dart
Outdated
// The compose box, when present, pads the bottom inset. | ||
// TODO this copies the details of when the compose box is shown; | ||
// if those details get complicated, refactor to avoid copying. | ||
removeBottom: widget.narrow != const AllMessagesNarrow(), |
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.
removeBottom: widget.narrow != const AllMessagesNarrow(), | |
removeBottom: widget.narrow is! AllMessagesNarrow, |
Because we override ==
, the two forms are actually exactly equivalent. But the is
form is what appears in the ComposeBox
logic, and I think is also the right conceptual framing of it. (For example if we somehow had two variants of AllMessagesNarrow
— perhaps a boolean for whether to exclude muted? — then they'd still presumably both skip the compose box.)
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.
Makes sense.
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.
(For example if we somehow had two variants of
AllMessagesNarrow
— perhaps a boolean for whether to exclude muted? — then they'd still presumably both skip the compose box.)
Yeah. Incidentally, I've become a little wary that AllMessagesNarrow
might not always mean what we think it means. Here's its dartdoc:
/// The narrow called "All messages" in the UI.
///
/// This does not literally mean all messages, or even all messages
/// that the user has access to: in particular it excludes muted streams
/// and topics.
And yet:
- Doesn't the "All messages" message list include even muted messages?
- When we
.apiEncode()
this narrow and send it to the server for mark-all-as-read, it's taken to mean all messages, including muted ones.
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.
- Doesn't the "All messages" message list include even muted messages?
It does, but that's because we haven't implemented muting yet. When we implement #346, one piece of it is to have the muting control
which messages are shown in stream narrows and the all-messages narrow.
2. When we
.apiEncode()
this narrow and send it to the server for mark-all-as-read, it's taken to mean all messages, including muted ones.
Hmm true. And that's intended behavior: it's the same as the specialized endpoint https://zulip.com/api/mark-all-as-read does, and the same as the web UI does.
So possibly the better way to conceptualize this narrow (vs. what the quoted doc comment says) is that the narrow does include muted messages, but the message list only shows a subset of the messages in the narrow, namely those that aren't muted.
I'll think more about that when I take up #346.
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.
It does, but that's because we haven't implemented muting yet.
Huh, TIL (or today I reminded myself) that zulip-mobile's "All messages" view also seems to filter out messages in muted conversations. 😅 (I almost never use that view myself.)
af94f47
to
e0a4ad2
Compare
…Er, now it does! 😂 Thanks for making that connection! Revision pushed. Updated to get the scroll-to-bottom button out of the inset, and to add TODOs about how we'd do things differently if we do a bottom nav, which would pad the bottom inset. Quoting myself from #263:
|
child: SafeArea( | ||
child: ScrollToBottomButton( |
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.
Ah yes, I see.
Great, thanks! Looks good; merging. |
This takes advantage of some of StickyHeaderListView's default behavior (inherited from ListView). From the doc on ListView: https://api.flutter.dev/flutter/widgets/ListView-class.html > By default, ListView will automatically pad the list's scrollable > extremities to avoid partial obstructions indicated by > MediaQuery's padding. To avoid this behavior, override with a zero > padding property. The code changes here are just to arrange for that default behavior to help us out: we let the real height of the bottom inset propagate down to the StickyHeaderListView, with the MediaQuery mechanism.
e0a4ad2
to
627515b
Compare
This takes advantage of some of StickyHeaderListView's default behavior (inherited from ListView). From the doc on ListView:
https://api.flutter.dev/flutter/widgets/ListView-class.html
The code changes here are just to arrange for that default behavior to help us out: we let the real height of the bottom inset propagate down to the StickyHeaderListView, with the MediaQuery mechanism.
Fixes: #263