feat add processing conversation on desktop

[krushnarout]

[gemini-code-assist]

Code Review

This pull request introduces a widget to display conversations that are currently being processed on the desktop version of the application. The implementation is clean and integrates well with the existing conversation list. I have one suggestion to improve the new widget by making it display dynamic data instead of being a static placeholder, which also resolves an unused parameter issue.

[beastoin]

Hey @krushnarout, sorry about the delay on this — @beastoin doesn't have bandwidth to review it right now and doesn't have any plans to in the near future.

@aaravgarg, could you take a look and make the call on this one? Feel free to approve and merge if it looks good to you. Thanks both!

[github-actions]

Hey @krushnarout 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

• Project standards — Ensuring consistency across the codebase
• User needs — Making sure changes align with what our users need
• Code best practices — Maintaining code quality and maintainability
• Project direction — Keeping aligned with our roadmap and vision

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community! 💜

[beastoin]

This was delegated for review but the reviewer never followed up, and it was silently closed without explanation. That's a process gap on our end. If you'd like to resubmit, we'll make sure it gets a proper review.

[beastoin]

Hey @krushnarout — thanks for this contribution, and sorry again for the delegation gap on our end. You submitted this, it was delegated for review, the reviewer never followed up, and then it was closed without explanation. That's entirely on us.

We've now reviewed the full diff and wanted to share feedback:

What's good:

• The processing widget integrates cleanly with the existing desktop conversation list architecture
• Your screenshot showed the intended UI placement
• You iterated on the styling (matching the conversation card pattern) which shows attention to design consistency

Items that need attention:

1. Visibility gap in empty-history state (high)
The processing widget is placed inside the sliver list that only renders when the user has existing conversations (hasAnyConversationsInSystem). Users with zero completed conversations — which is exactly when a "processing..." indicator matters most (first recording) — will never see it, because they get routed to the empty-state view instead.

2. Widget doesn't use the conversation data (medium)
The widget accepts a conversation parameter but doesn't render any of its data — it shows only a generic "Processing..." placeholder. Displaying the actual conversation details (timestamp, duration, segment count) would make this more useful and match the mobile version's behavior.

3. No test coverage (low)
A widget test verifying the conditional rendering based on processingConversations state would strengthen confidence — especially for the empty-history edge case above.

Path forward:
If you'd like to resubmit, addressing the visibility gap (#1) would be the key fix — making sure the processing indicator shows up regardless of whether the user has prior conversations. We'll assign a specific reviewer upfront this time so there's no delegation gap.

Thanks for contributing to Omi.

[beastoin]

@krushnarout Some pointers on the items mentioned above:

Empty-history visibility: The processing widget is inside the sliver list that only renders when hasAnyConversationsInSystem is true. But that flag is based on completed conversations only — so first-time users with only processing conversations never see it. Look at how the mobile app handles this in conversations_page.dart — the processing widget is rendered independently of the completed-conversations check. You'd want similar logic on desktop: check processingConversations.isNotEmpty separately and show the widget even when the history is empty.

Using real conversation data: The widget currently accepts a conversation parameter but renders a static placeholder. The ServerConversation object has useful fields (createdAt/startedAt, transcriptSegments.length, status, structured.title) that would make the widget more informative. Look at the mobile processing conversation widgets in app/lib/pages/conversations/widgets/ for the pattern.

Review ownership: If you resubmit, we'll assign a specific reviewer upfront — no more delegation gaps.

Let us know if you'd like to pick this back up.

[github-actions]

Hey @krushnarout 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

• Project standards — Ensuring consistency across the codebase
• User needs — Making sure changes align with what our users need
• Code best practices — Maintaining code quality and maintainability
• Project direction — Keeping aligned with our roadmap and vision

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community! 💜