Skip to content

Edit-message (4/n): Misc. preparation for edit-message feature #1471

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

Merged
merged 7 commits into from
Apr 18, 2025

Conversation

chrisbobbe
Copy link
Collaborator

Here's a small batch of miscellaneous prep work for the edit-message feature, #126.

@chrisbobbe chrisbobbe added the maintainer review PR ready for review by Zulip maintainers label Apr 10, 2025
@chrisbobbe chrisbobbe requested a review from PIG208 April 10, 2025 01:54
Copy link
Member

@PIG208 PIG208 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This looks good to me overall. Left a small comment, and marking for Greg's review.

@@ -21,11 +21,11 @@ Widget _dialogActionText(String text) {
///
/// See also:
/// * [showDialog], whose return value this class is intended to wrap.
class DialogStatus {
class DialogStatus<T> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be helpful to document the meaning of the type parameter. Specially, from showDialog, this part seems relevant:

/// If the application has multiple [Navigator] objects, it may be necessary to
/// call `Navigator.of(context, rootNavigator: true).pop(result)` to close the
/// dialog rather than just `Navigator.pop(context, result)`.
///
/// Returns a [Future] that resolves to the value (if any) that was passed to
/// [Navigator.pop] when the dialog was closed.

We just need to adapt it to fit our wrapper class.

@PIG208 PIG208 assigned gnprice and unassigned PIG208 Apr 10, 2025
@PIG208 PIG208 requested a review from gnprice April 10, 2025 23:43
@PIG208 PIG208 added integration review Added by maintainers when PR may be ready for integration and removed maintainer review PR ready for review by Zulip maintainers labels Apr 10, 2025
Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Generally this looks good; a couple of small comments (adding to Zixuan's above).

Comment on lines 27 to 44
/// Resolves when the dialog is closed.
final Future<void> closed;
final Future<T?> closed;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the meaning of the value that this resolves to?

(I think this question overlaps with Zixuan's comment above.)

actionButtonText: 'Sure',);
await tester.pump();
await tester.tap(find.text('Sure'));
await check(dialog.closed).completes((it) => it.equals(SuggestedActionDialogResult.doAction));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: line too long: key information past 80 columns (namely the only information that distinguishes this check from its opposite in the other test case 🙂)

To avoid wasting a lot of vertical space in the edit-message compose
box (coming up) with large text-scale settings.

Related: zulip#1023
Move vertical padding so it won't wrap the trailing element, when
present (as a `buildTrailing` that returns non-null). When we add
the "Cancel" and "Save" buttons for the edit-message banner, those
will want to control their own outer vertical padding to make it
respond to taps, because the painted button is supposed to be just
28px tall, which is too small for a touch target; see discussion
linked in dartdoc.

NFC because `buildTrailing` on _Banner's only subclass,
_ErrorBanner, returns null.
@chrisbobbe
Copy link
Collaborator Author

Thanks for the reviews! Revision pushed.

child: _dialogActionText(actionButtonText ?? zulipLocalizations.dialogContinue)),
]));
return DialogStatus(_wrapFutureExpectingNonNull(future));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah interesting.

What happens if the user tries to dismiss the dialog without tapping either button? E.g. by tapping outside the dialog's area (on the obscured remainder of the page that's under the dialog), or by using the Android "back" gesture/button.

I think we'd want to have those work, and have the same effect as tapping the "Cancel" button.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, thanks for catching this—addressing this in the new revision.

@chrisbobbe
Copy link
Collaborator Author

Thanks for the review! Revision pushed.

logOutAccount(GlobalStoreWidget.of(context), accountId);
});
actionButtonText: zulipLocalizations.logOutConfirmationDialogConfirmButton);
if (await dialog.closed == true) {
Copy link
Collaborator Author

@chrisbobbe chrisbobbe Apr 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, hmm, I guess this doesn't look ideal. What it means is "did the user press the 'Log out' button", but what it looks like it means is "was the dialog closed".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. Maybe rename the field, say to result?

Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the revision! LGTM modulo the subthread above, and two nits below.

/// If this completes with null, the dialog was dismissed.
/// Otherwise, completes with a [T] identifying the interaction's outcome.
///
/// See, e.g., [showSuggestedActionDialog] and [SuggestedActionDialogResult].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: the latter reference no longer exists

context: context,
builder: (BuildContext context) => AlertDialog(
title: Text(title),
content: SingleChildScrollView(child: Text(message)),
actions: [
TextButton(
onPressed: () => Navigator.pop(context),
onPressed: () => Navigator.pop<bool?>(context, null),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: the types allow bool here (and below):

Suggested change
onPressed: () => Navigator.pop<bool?>(context, null),
onPressed: () => Navigator.pop<bool>(context, null),

and that seems a bit more consistent with bool as the type parameter on showDialog

With this API, we can use showSuggestedActionDialog in an "early
return" style -- await the user's choice, and early return if they
chose to dismiss the dialog. That's particularly helpful when the
confirmation dialog is opened in an `if` block.

We'll use this for the upcoming "edit message" feature (zulip#126), where
we plan to offer a confirmation dialog before entering an
edit-message session, but only if the compose box has text for a new
message in it (which would be discarded if the user wants to go
ahead).
@chrisbobbe
Copy link
Collaborator Author

Thanks for the review! Revision pushed.

@gnprice
Copy link
Member

gnprice commented Apr 18, 2025

Thanks! Looks good; merging.

@gnprice gnprice merged commit 4596245 into zulip:main Apr 18, 2025
1 check passed
@chrisbobbe chrisbobbe deleted the pr-edit-message-4 branch April 18, 2025 05:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integration review Added by maintainers when PR may be ready for integration
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants