message-list : add a prompt to notify guest(s) when DM

[Abhisheksainii]

Fixes #798

Changes made:

Add a prompt above composeBox to notify the user if the recipient is a guest or not. Attaching screenshots and video for reference.

WhatsApp.Video.2025-02-16.at.13.08.40.mp4

[gnprice]

Thanks!

Marking as draft since this won't be ready for review until it has tests.

For help writing tests, the best place to ask is in Zulip in #mobile-dev-help.

[Abhisheksainii]

@gnprice I think the PR is ready for review. Let me know if I need to do some changes beforehand.

[chrisbobbe]

I'm seeing a lot of changes that don't look related to the work that's needed; please remove those. Also, CI is failing; you'll need to fix that.

[Abhisheksainii]

I'm seeing a lot of changes that don't look related to the work that's needed; please remove those. Also, CI is failing; you'll need to fix that.

@chrisbobbe it will help a lot if you can mention the changes that seem not required, either here or I can create a topic in mobile-dev-help channel.

[chrisbobbe]

For example I see many changes in test/widgets/message_list_test.dart that just change the code formatting (line breaks, indentation, etc.). This is very distracting to a reader who wants to understand the meaningful, intended changes in the commit.

[Abhisheksainii]

@chrisbobbe unnecessary fixes removed and CI checks passed.

[gnprice]

As I wrote in January (#1143 (comment)), in order for us to spend time reviewing your work, you need to do a better job of self-reviewing it first.

The comments above are all things you should have spotted in self-review. This revision is better than the first one, but still doesn't meet our standards for clear commits (which are linked in our README and in several comments on #1143 from December): among other things there are still unrelated changes (though fewer of them), and the tests are separated from the code they test.

The logic of the implementation also needs a lot of changes before it's something we can merge. Among other things:

• It iterates through every user in the whole realm, which is inefficient, and it does so in a build method. Flutter build methods can get called frequently, and so need to be kept efficient.
• The way the new code interacts with the rest of the widget isn't normal Flutter style (which would call for a new widget), and isn't like any other existing code around it.

---

So @Abhisheksainii based on #1143 and now this thread, I think you don't yet have the skills to learn to contribute productively in the Zulip project. You're welcome to try again after at least 6 months.

I recommend you spend time working on other projects, and reading a lot of code, especially reading code in well-maintained codebases like Zulip or upstream Flutter (i.e., any of the main repositories at https://github.com/zulip or https://github.com/flutter). This advice from our contributing guide is applicable to a wide variety of codebases:

• Set up a development environment following the instructions in the project README.
• Start reading recent commits to see the code we’re writing. Use either a graphical Git viewer like gitk, or git log -p with the “secret” to reading its output.
• Pick some of the code that appears in those Git commits and that looks interesting. Use your IDE to visit that code and to navigate to related code, reading to see how it works and how the codebase is organized.

I recommend also investing effort in clearly explaining why your changes work correctly. As our guide to reviewable PRs says, that begins with clearly reasoning through that question yourself:

When you write code, you should make sure that you understand why it works as intended. This is the foundation for being able to explain your proposed changes to others.

Even in personal projects where nobody else is reading your explanations, taking the time to clearly write them down will help you write higher-quality code. It will also be useful practice for contributing to projects like Zulip where there are other people you need to explain your changes to.

[Abhisheksainii]

As I wrote in January (#1143 (comment)), in order for us to spend time reviewing your work, you need to do a better job of self-reviewing it first.

The comments above are all things you should have spotted in self-review. This revision is better than the first one, but still doesn't meet our standards for clear commits (which are linked in our README and in several comments on #1143 from December): among other things there are still unrelated changes (though fewer of them), and the tests are separated from the code they test.

The logic of the implementation also needs a lot of changes before it's something we can merge. Among other things:

• It iterates through every user in the whole realm, which is inefficient, and it does so in a build method. Flutter build methods can get called frequently, and so need to be kept efficient.
• The way the new code interacts with the rest of the widget isn't normal Flutter style (which would call for a new widget), and isn't like any other existing code around it.

---

So @Abhisheksainii based on #1143 and now this thread, I think you don't yet have the skills to learn to contribute productively in the Zulip project. You're welcome to try again after at least 6 months.

I recommend you spend time working on other projects, and reading a lot of code, especially reading code in well-maintained codebases like Zulip or upstream Flutter (i.e., any of the main repositories at https://github.com/zulip or https://github.com/flutter). This advice from our contributing guide is applicable to a wide variety of codebases:

• Set up a development environment following the instructions in the project README.
• Start reading recent commits to see the code we’re writing. Use either a graphical Git viewer like gitk, or git log -p with the “secret” to reading its output.
• Pick some of the code that appears in those Git commits and that looks interesting. Use your IDE to visit that code and to navigate to related code, reading to see how it works and how the codebase is organized.

I recommend also investing effort in clearly explaining why your changes work correctly. As our guide to reviewable PRs says, that begins with clearly reasoning through that question yourself:

When you write code, you should make sure that you understand why it works as intended. This is the foundation for being able to explain your proposed changes to others.

Even in personal projects where nobody else is reading your explanations, taking the time to clearly write them down will help you write higher-quality code. It will also be useful practice for contributing to projects like Zulip where there are other people you need to explain your changes to.

No problem, Thanks for the guidance. I will make sure that I work up on my ability to read the code and self-review it.