Skip to content

feat: add capture:screenshot IPC handler#15

Open
markdavis8898 wants to merge 10 commits into
sightflow-dev:mainfrom
markdavis8898:pr/screenshot-capture
Open

feat: add capture:screenshot IPC handler#15
markdavis8898 wants to merge 10 commits into
sightflow-dev:mainfrom
markdavis8898:pr/screenshot-capture

Conversation

@markdavis8898

Copy link
Copy Markdown

Adds a new IPC channel capture:screenshot that allows programmatic capture of the current browser page and saves it as PNG.

  • Accepts optional savePath parameter (defaults to desktop)
  • Returns { success, path } or { success: false, error }
  • Useful for automated screenshots, debugging, and external agent integration

No breaking changes. All existing IPC channels remain unaffected.

@guangzhengyu

Copy link
Copy Markdown
Collaborator

抱歉,前些天太忙了,没来及review。我努力在今明两天review并comment 💪

@guangzhengyu

guangzhengyu commented Jun 4, 2026

Copy link
Copy Markdown
Collaborator

@markdavis8898 你好~~ 非常感谢你对sightflow项目的关注和贡献~ 当前pr我review之后发现有一些问题,如果要合入main还需要一些修改哈

这里我先补充一下当前 Provider 体系的设计意图。

我们的目标是让外部开发者可以独立开发一个 Provider,而不需要修改 SightFlow Desktop 的主代码。也就是说,一个第三方 Provider 理论上不应该通过改 App.tsx、改主进程内置 Provider 逻辑,或者把 bundle 直接塞进主仓库来接入。

外部开发者只需要做几件事:

  1. 实现一个 Provider bundle,例如 provider.bundle.js,导出符合约定的 createProvider()
  2. 编写一个 manifest.json,声明 Provider 的 idnameversionentrycapabilitiesconfigSchema
  3. manifest.jsonprovider.bundle.js 放到一个可访问的位置,比如自己的 HTTPS 服务;本地开发阶段也可以用 file:// 路径。
  4. 让 Provider catalog / hub 返回这个 Provider 的 manifestUrl

当前 app 的流程是:

Provider Hub
  -> 返回 Provider catalog
  -> catalog item 里有 manifestUrl
  -> app 通过 manifestUrl 读取 manifest
  -> manifest 声明 provider.bundle.js
  -> app 安装并加载这个 bundle

目前 Hub 地址是由我作为 owner 维护的地址。外部开发者在测试阶段如果想验证自己的 Provider,可以 mock 这个 hub 的 HTTP 返回,或者直接用本地 file://.../manifest.json 做安装测试。测试ok了可以再给我进行Hub的修改。未来会开放hub到可公开提审的流程里,不过目前先“糙”一点、人肉点哈~

综上: Provider 的接入点应该是 manifest / hub,而不是直接修改 renderer 里的 built-in catalog,也不是在主仓库里硬编码一个新的 builtin://xxx

你现在的做法是:

manifestUrl: 'builtin://opencode-go-kimi'

并且把 opencode-go-kimi 的 bundle 直接加进了主仓库。这和当前 Provider 体系的设计意图不相符。

builtin:// 目前不是一个通用 Provider 协议。现在只有 Doubao 是特殊的内置 Provider,因为它有主进程里的专门 fallback / loader 逻辑。只在前端 catalog 里添加 builtin://opencode-go-kimi,并不会让它成为一个真正可安装、可加载的 Provider。

如果你想接入 opencode-go-kimi,建议按第三方 Provider 的方式做:

  1. 准备 manifest.json
  2. 准备 provider.bundle.js
  3. 用 HTTPS 或本地 file:// 暴露 manifest
  4. 通过 mock provider hub 或本地安装流程测试它

未来也不会添加任何built-in Provider了~ 因为外部provider就是为了可扩展、不必侵入式改动而设计的

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