Skip to content

feat(desktop): make QQ sessions usable from desktop#1334

Merged
esengine merged 5 commits into
esengine:mainfrom
wade19990814-hue:codex/desktop-qq-parity
May 20, 2026
Merged

feat(desktop): make QQ sessions usable from desktop#1334
esengine merged 5 commits into
esengine:mainfrom
wade19990814-hue:codex/desktop-qq-parity

Conversation

@wade19990814-hue

@wade19990814-hue wade19990814-hue commented May 19, 2026

Copy link
Copy Markdown
Contributor

Summary

Context

Testing

  • npm test -- --run tests/desktop-qq-settings-ui.test.ts tests/desktop-user-message.test.ts tests/desktop-qq-config.test.ts
  • npm run typecheck
  • npm run lint
  • npm run verify

@wade19990814-hue wade19990814-hue force-pushed the codex/desktop-qq-parity branch from b6593cc to ed791d2 Compare May 19, 2026 12:47
@wade19990814-hue wade19990814-hue force-pushed the codex/desktop-qq-parity branch from ed791d2 to 76c06c3 Compare May 19, 2026 12:48

Copy link
Copy Markdown
Contributor Author

Context for reviewers: #1317 surfaced that desktop QQ was only acting as a config editor while the UI implied a live connection. #1326 corrected that by stopping desktop from claiming “Connected” without a real runtime behind it.

This PR builds on that baseline rather than undoing it. It keeps the tighter settings surface, but also wires QQ into the active desktop session so the connected state becomes real again: desktop now starts/stops a real QQ runtime, QQ messages enter the current active tab, inbound user messages are shown in the desktop transcript, and desktop replies route back to QQ.

So the relationship is:

@wade19990814-hue wade19990814-hue changed the title fix(desktop): polish QQ settings and surface inbound messages feat(desktop): make QQ sessions usable from desktop May 19, 2026

Copy link
Copy Markdown
Contributor Author

@esengine Small product signal: #1343 was opened right after this landed in front of users, and it lines up with the same gap this PR is addressing. The current desktop surface is discoverable enough that people are already trying to configure QQ there, but they then hit the exact mismatch from #1317: config is present, yet active-session QQ runtime is still missing on main.

So in addition to the code path itself, #1343 is a concrete sign that this is not just internal cleanup; users are already reaching for desktop QQ and interpreting the current surface as a usable integration entrypoint.

@esengine esengine merged commit 18ee05d into esengine:main May 20, 2026
4 checks passed
@esengine

Copy link
Copy Markdown
Owner

Thanks @wade19990814-hue — this is a solid piece of work and a good direction for us. Glad you went after the underlying gap from #1317 instead of stopping at the labelling fix. I'll do a small follow-up PR to re-add the augmentProcessPath() call that #1331 introduced (it got dropped in your rebase, unrelated to the QQ work — no need to touch it on your side). Looking forward to more contributions like this; we want the IM bridge surface to grow (QQ today, room for Feishu / Discord / etc later) and having maintainers in that space is exactly what we need.

esengine added a commit that referenced this pull request May 20, 2026
#1331 added augmentProcessPath() in desktopCommand so the Tauri-spawned
Node could see nvm/asdf/fnm/volta/mise PATH entries — the GUI process
never runs the user's shell init. #1334 was branched before #1331 landed
and the rebase dropped the import + call without it being part of the
QQ-runtime work.

Re-add the import and the call site, no behavior change beyond restoring
the previous fix.

Co-authored-by: reasonix <reasonix@deepseek.com>
@wade19990814-hue wade19990814-hue deleted the codex/desktop-qq-parity branch May 23, 2026 04:39
ChasLui pushed a commit to ChasLui/DeepSeek-Reasonix that referenced this pull request May 23, 2026
ChasLui pushed a commit to ChasLui/DeepSeek-Reasonix that referenced this pull request May 23, 2026
…se (esengine#1361)

esengine#1331 added augmentProcessPath() in desktopCommand so the Tauri-spawned
Node could see nvm/asdf/fnm/volta/mise PATH entries — the GUI process
never runs the user's shell init. esengine#1334 was branched before esengine#1331 landed
and the rebase dropped the import + call without it being part of the
QQ-runtime work.

Re-add the import and the call site, no behavior change beyond restoring
the previous fix.

Co-authored-by: reasonix <reasonix@deepseek.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants