compose_box: Add start video call button in compose

[MritunjayTiwari14]

Fixes #1824

Design

Before	After	After(Clicking Button)
	R

Light Theme

XRecorder_20251015_04.mp4

Dark Theme

XRecorder_20251015_05.mp4

[gnprice]

Thanks. It looks like you still have a TODO item before this is ready to be reviewed, so marking it as draft for now.

[MritunjayTiwari14]

All the TODO are done @gnprice!

[gnprice]

Thanks. Before this can be reviewed, you'll need to revise it to have clear and coherent commits. See the instructions we discussed on a previous PR thread: #1830 (review)

[MritunjayTiwari14]

Thanks @gnprice for suggesting the refinement in commit history to make sure it becomes minimal and coherent. The same has been implemented.

[gnprice]

Thanks. Some of these commits aren't coherent. For example this commit f314a74:

    deps: Update pigeon to `26.0.2` from `26.0.1`
    
    This commit is the result of the following commands:
        flutter pub upgrade --major-version pigeon
        tools/check --all-files --fix pigeon
    
    Changelog:
    
    https://pub.dev/packages/pigeon/changelog#2602
---
 .../kotlin/com/zulip/flutter/AndroidIntents.g.kt    | Bin 6118 -> 6118 bytes
 .../com/zulip/flutter/AndroidNotifications.g.kt     | Bin 30643 -> 30643 bytes
 ios/Runner/Notifications.g.swift                    |   2 +-
 3 files changed, 1 insertion(+), 1 deletion(-)

can't be right, because it says it involved flutter pub upgrade but there's no change to pubspec.lock.

One useful step for spotting this kind of issue is to run our tests at every commit. If they fail, the commit needs fixing.

It's straightforward to do that by hand. But a command which can be a useful shortcut for it is this:
git rebase --exec 'tools/check --diff @~'

[MritunjayTiwari14]

Thank you @gnprice for taking time to review the commit history and for the useful shortcut. It was very handy and i was easily able to trace the coherent status of each commit and resolve them on the go.

Following i have done the updates in the commit history to maintain coherent commit with optimized minimalism.

[gnprice]

These commits still aren't coherent. As of this commit:
e47d7c0 button: Add video chat button in compose box

there's a button which doesn't do anything. That would be a buggy, broken experience for a user who tries it.

Before you ask others to review your work, it's important to take the time to read and review it carefully yourself. Reviewers' time is limited; and when reviewers have to point out the same kinds of issues repeatedly, it's not an efficient use of their time.

[MritunjayTiwari14]

Thank you @gnprice for the review. I understand maintainer and review have restricted time to point out same issue again and respect their time so to avoid this in future.

This problem is due to mainly me trying to understand the coherent commit style of Zulip codebase and i am trying my best to adapt it. Just a few clarification would help me to understand them more from your side and avoid these type of situations in the future:

• Is there a need for the Implemented code for the button in compose_box to be split into multiple commits, as i personally feels the code size is moderate enough to squash all the commit related to button in a single commit?
• As coherent commits also means each commit should be ready for deployment independent of the other, so this also means the current commit should be deployable irrespective of the previous and the upcoming commit?

Also the updated commit history has been pushed. 🙂

[gnprice]

• Is there a need for the Implemented code for the button in compose_box to be split into multiple commits, as i personally feels the code size is moderate enough to squash all the commit related to button in a single commit?

Yeah, these changes make sense as a single commit:
60c8e0d compose: Add video chat button to compose box

• As coherent commits also means each commit should be ready for deployment independent of the other, so this also means the current commit should be deployable irrespective of the previous and the upcoming commit?

Each Git commit includes a particular tree, a complete state of all the files that are tracked in the repository. That tree reflects the changes made in that commit, and also all the changes made in the previous commits that are part of that commit's ancestry.

So when we say each commit should be deployable on its own, we're referring to the commit's whole tree. The commit shouldn't change the tree into a state that we couldn't happily deploy.

If you were to take the same changes the commit makes, though, and apply those changes to some other tree — for example if you were to drop the previous commits in a PR branch, and apply the commit's changes directly to the tree that's in the main branch — then that would be a different tree. Naturally sometimes that hypothetical tree will be one that one wouldn't want to deploy (or that wouldn't even be possible to deploy, because it wouldn't compile). What's important is that each of the states of the tree that actually appear in your branch are good to deploy.

[MritunjayTiwari14]

Thank you @gnprice for the detailed explanation.