Message List from Same User is now Distinguishable via Surface Tint on Long Press

[Gaurav-Kushwaha-1225]

Changes Made

This issue resolved by:

• Wrapping the MessageWithPossibleSender with a Container
• Then, giving it a color property on a condition that when isMessageActionSheetOpen is true show the surface tint, else remain Colors.transparent.

For this,

• I shifted the MessageWithPossibleSender from StatelessWidget to StatefulWidget.
• Added a nullable VoidCallback? onDismiss method in parameters of showMessageActionSheet or BottomSheet for updating the Surface Tint of message.

Fixes #1142

Screenshots

Light Theme	Dark Theme
video_2024-12-13_13-16-02.mp4	video_2024-12-13_13-16-08.mp4

[alya]

Please post screenshots of your changes in the PR description, as videos are hard to review.

[Gaurav-Kushwaha-1225]

Please post screenshots of your changes in the PR description, as videos are hard to review.

Changes

1st

• shifting the MessageWithPossibleSender widget from StatelessWidget to StatefulWidget.
• adding isMessageActionSheetOpen and pressedTint as parameters of MessageWithPossibleSender for making surface value tint to transparent after bottom sheet is closed.
• Screenshot:

2nd

• Wrapped with Container with color property on isMessageActionSheetOpen condition.
• Updating the function of onLongPress of MessageWithPossibleSender widget. That, when isMessageActionSheetOpen is true show the surface tint.
• Screenshot:

3rd

• Just adding a nullable VoidCallback? onDismiss method in parameters of showMessageActionSheet and _showActionSheet for getting response of closing of bottom sheet.
• Screenshots:
• 
• 

[chrisbobbe]

Alya means before/after screenshots of the app's UI. We can read your code easily without screenshots :)

[chrisbobbe]

Also I see there's a failing check; please run tests locally (tools/check) and fix any failures.

[Gaurav-Kushwaha-1225]

Alya means before/after screenshots of the app's UI. We can read your code easily without screenshots :)

I am sorry for the confusion.
Here, are the screenshots:

Before	After

Also I see there's a failing check; please run tests locally (tools/check) and fix any failures.

I have updated the changes and there are no failing checks and conflicts now.
Thank you.

[alya]

Are those before/after scheenshots the same? The point is to show the differences from your PR's changes.

[Gaurav-Kushwaha-1225]

Are those before/after scheenshots the same? The point is to show the differences from your PR's changes.

@alya,
In the screenshots, the message on which the user has long pressed, that message has appeared a surface tint color separating from rest other messages, in both light and dark theme.
This was the issue to resolve i.e. to give a surface tint to those messages where long press event has occurred.

[alya]

Oh, I see it now.

Is it happening in the dark theme screenshot? I don't see a difference, so if the effect is there, it's too subtle.

[alya]

It's also best to take screenshots that are identical other than the change your PR makes, to make them easy to compare.

[Gaurav-Kushwaha-1225]

Oh, I see it now.

Is it happening in the dark theme screenshot? I don't see a difference, so if the effect is there, it's too subtle.

@alya
Yeah, actually I took the same tint color for both themes. I saw in the figma file both are different for different themes.
I will update the PR in few minutes.
Sorry, for my inconvenience.

[alya]

Sure, please be mindful to review your own work carefully next time. Posting screenshots is one of the things that should help you identify any problems yourself, before asking someone else to take a look.

[Gaurav-Kushwaha-1225]

@alya

Here, is the updated PR.

Requirements according to Figma File

• 
• 

Before and After Screenshots

NOTE: In after screenshots, you may see the colors appearing to be a bit different (or less light/dark) from actual figma. This is because the action sheet is opened in my after screenshots which are not in figma file.

Before	After

Both pressedTint colors in light and dark theme are according to the Figma File i.e. RGBA(0, 0, 0, 0.04) for light theme and RGBA(1, 1, 1, 0.04) for dark theme.

[PIG208]

Hi @Gaurav-Kushwaha-1225! Thanks for the updates. For the PR to be reviewable, we need tests for this: https://github.com/zulip/zulip-flutter?tab=readme-ov-file#submitting-a-pull-request

Please also pay attention to the point on commit style guide from that link, and organize the commit history coherently.

[chrisbobbe]

I see you're adding merge commits; Zulip doesn't use those.

[Gaurav-Kushwaha-1225]

Hi @Gaurav-Kushwaha-1225! Thanks for the updates. For the PR to be reviewable, we need tests for this: https://github.com/zulip/zulip-flutter?tab=readme-ov-file#submitting-a-pull-request

Please also pay attention to the point on commit style guide from that link, and organize the commit history coherently.

Hi @PIG208, I have added the necessary tests for these changes in test/widgets/message_list_test.dart file.
Please review the changes and feature added.
Thank you.

[PIG208]

Looks like this update still hasn't addressed my previous comment on the commit style:

Please also pay attention to the point on commit style guide from that link, and organize the commit history coherently.

As Chris said, we don't use merge commits. Could you please also review the commit style guide linked in our README?

[Gaurav-Kushwaha-1225]

Looks like this update still hasn't addressed my previous comment on the commit style:

Please also pay attention to the point on commit style guide from that link, and organize the commit history coherently.

As Chris said, we don't use merge commits. Could you please also review the commit style guide linked in our README?

I’ve updated the commits, improving the commit style and making other enhancements.
I believe it’s ready for review now.

Please let me know if any further changes are required.

[chrisbobbe]

Thanks! Comments below. Please also squash these two commits into one, so the tests land in the same commit as the code they're testing.

[chrisbobbe]

Since this comes from a variable in the Figma, please move it so it's with the other Figma variables: background, bannerBgIntDanger, etc., and put it there alphabetically, so (in current main) between mainBackground and textInput.

(And reorder its other appearances accordingly)

[Gaurav-Kushwaha-1225]

It is named as pressedTint itself in the design file.
And, regarding the reordering, that I will reorder and update soon.

[chrisbobbe]

If isMessageActionSheetOpen is supposed to mean what its name says, it isn't accurate here. The action sheet won't be open until 100ms have passed.

I'd like to try a different approach, using an existing Flutter API that seems suitable.

• _MessageWithPossibleSenderState gets a new final field:

    final WidgetStatesController statesController = WidgetStatesController();

• Override _MessageWithPossibleSenderState.initState like so:

    @override
    void initState() {
      super.initState();
      statesController.addListener(() {
        setState(() {
          // Force a rebuild to resolve background color
        });
      });
    }

• Override _MessageWithPossibleSenderState.dispose, calling statesController.dispose()

• In addition to the existing onLongPress, pass onLongPressDown, onLongPressCancel, and onLongPressUp to the GestureDetector. Each passed callback should call statesController.update(WidgetState.pressed, … with true or false as appropriate.

• At the top of the existing onLongPress calback, call statesController.update(WidgetState.selected, true). When the action sheet is dismissed, unset that with false.

• For the background color, use:

              color: const WidgetStateColor.fromMap({
                WidgetState.pressed: designVariables.pressedTint,
                WidgetState.selected: designVariables.pressedTint,
                WidgetState.any: Colors.transparent,
              }).resolve(statesController.value)

[chrisbobbe]

I don't think we want an additional 100ms delay here; let's remove it.

[gnprice]

In addition to Chris's comments above, one other high-level comment. (I've only done an initial skim of this PR, since it's still in maintainer review.)

[gnprice]

This type of API based on callbacks can make the control flow pretty confusing to follow. The behavior here can be more cleanly modeled using Future.

Let's also avoid using explicit Future methods like whenComplete, in favor of async and await.

Concretely, let's have this function _showActionSheet, and its caller showMessageActionSheet, mimic the API we developed for showErrorDialog:

/// Displays an [AlertDialog] with a dismiss button.
///
/// The [DialogStatus.closed] field of the return value can be used
/// for waiting for the dialog to be closed.
// This API is inspired by [ScaffoldManager.showSnackBar].  We wrap
// [showDialog]'s return value, a [Future], inside [DialogStatus]
// whose documentation can be accessed.  This helps avoid confusion when
// intepreting the meaning of the [Future].
DialogStatus showErrorDialog({

We can use the same DialogStatus type for the return value. I'll update your PR branch with a quick prep commit that gives it a slightly more general name ModalStatus, and slightly more general docs, so that it's ready to be used that way.

[gnprice]

I'll update your PR branch with a quick prep commit

Done. @Gaurav-Kushwaha-1225 As the first step when you start work on your next revision, be sure to pull down the updated version of this branch — use git fetch me or git fetch origin, whatever name you use for the remote pointing at your GitHub fork of this repo. (If you're unsure how to do this, the #git help channel is a good place for questions.)