-
Notifications
You must be signed in to change notification settings - Fork 337
compose: Use "info" intent, not "danger", for cannot-post-here banners #1871
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
32f405e
to
5106d65
Compare
I guess the difference here is that this notice would always be visible in a channel you can't post in? Blue/info does seem reasonable in that case. |
Yeah, it's a non-dismissable banner that we show when we're not showing the compose box, because composing isn't allowed. I think "info" is appropriate because the user didn't do anything wrong and there wasn't any action that failed: they just want to catch up on |
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 @chrisbobbe! LGTM, moving over to Greg's review.
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 fixing this! A couple of comments below.
return _ErrorBanner(getLabel: (zulipLocalizations) => | ||
zulipLocalizations.errorBannerCannotPostInChannelLabel); | ||
return _Banner( | ||
intent: _BannerIntent.info, | ||
label: zulipLocalizations.errorBannerCannotPostInChannelLabel); |
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.
Neat, I like that the label is now found in a more straightforward way.
lib/widgets/compose_box.dart
Outdated
Widget build(BuildContext context) { | ||
// (A BuildContext that's expected to remain mounted until the whole page | ||
// disappears, which may be long after the banner disappears.) | ||
final pageContext = PageRoot.contextOf(context); |
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.
Hmm, this seems odd, though. If the banner disappears, this widget will get unmounted. In that case what's going to end up subsequently using this pageContext
value?
It looks to me like both the references below could just use context
directly, and that'd be the normal Flutter thing to do.
… Aha, down at the bottom of the _handleTapSave
implementation, it does actually want a longer-lasting context. (It awaits a request, and then might end up trying to display an error.) I think that's something that method should take care of, though.
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.
Probably cleanest to have a prep commit before this make the change to have buildTrailing
take the local context, and _handleTapSave
take care of getting the page context.
5106d65
to
bf0b314
Compare
Thanks for the reviews! Revision pushed. |
As we do for e.g. ZulipWebUiKitButton.
Instead of as a base class with subclasses _ErrorBanner and _EditMessageBanner.
Thanks! Looks good; merging. |
bf0b314
to
38a2c63
Compare
Fixes #1870.