希望输入队列支持拖拽排序

[moyx782]

摘要

Web UI 输入框上方的排队消息条(QueueDock)目前只支持编辑 / 删除 / 单条插队(steer)三个操作,排队顺序固定为发送顺序(FIFO),无法调整。希望为排队中的消息增加拖拽排序(以及键盘可达的替代操作),让用户能把更想先执行的消息移到前面。

现状(基于 0.1.0-rc.6 源码)

• UI:packages/client/ui-conversation 的 QueueDock 组件渲染排队条,每行操作仅有:
  • edit(编辑文本)
  • remove(删除)
  • steer(单条插队,agent 运行中可用)
• 协议:session.updateQueue RPC(dsh-host-apiproxy)的 action 是 discriminated union,仅三种:

  { kind: "edit", content: contentBlock[] } | { kind: "remove" } | { kind: "steer" }

• 队列顺序:严格 FIFO;steer 会把消息立即送进当前回合(steering placement),已在"插队"意义上存在,但不能改变普通排队消息之间的相对顺序。
• 现有拖拽代码仅用于附件/文件上传(composer 的 dragenter/dragover/drop),与队列无关。

期望行为

1. 排队条中每条消息可被拖拽到队列中的任意新位置(在两条消息之间放置);放下后顺序立即更新。
2. 提供键盘可达的替代操作(例如每行的上移/下移按钮或菜单),满足可访问性要求。
3. 重新排序后的顺序在回合开始时按新顺序 FIFO 执行。
4. 排序后依然可以编辑 / 删除 / 单条 steer,互不冲突。

实现建议

协议层(dsh-host-apiproxy / session 实现)

在 session.updateQueue 的 action union 中新增:

{ kind: "move", targetIndex: number }   // 移动到目标下标(0 = 队首)

或相对形式(原子性更简单):

{ kind: "move", direction: "up" | "down" }

• 越界下标 / 目标不存在 → 拒绝(可复用现有 queue-item-not-found 错误语义)。
• move 只允许作用于 placement === "queued" 的消息;已被 steer 的消息不可移动。

UI 层(packages/client/ui-conversation 的 QueueDock)

• 为每行增加拖拽把手(或整行可拖),复用/新增 pointer-based 拖拽(HTML5 DnD 与现有附件拖拽并存,注意事件冲突)。
• 拖拽期间高亮放置位置;放下时调用 updateQueue(itemId, { kind: "move", targetIndex })。
• 处于编辑态 / 操作进行中(busy)/ 子代理会话(queueMutable === false)时禁用拖拽,与现有按钮的禁用逻辑一致。
• 队列折叠(collapsed)状态不受影响。

验收标准

• 多消息排队时,可拖拽任意一条到任意位置,列表顺序即时更新。
• 新顺序在回合开始时按序执行(可观察:执行顺序与排序一致)。
• 单条消息时无拖拽 UI 或无意义操作。
• 编辑 / 删除 / steer 在新顺序下仍然可用。
• 上移/下移按钮(或其他键盘路径)可实现相同效果。
• 排序后刷新页面(若队列可恢复)顺序保持一致;若队列不可持久化,需在文档中说明。

备选方案

若拖拽实现成本过高,最小可用版本为:每行增加上移 / 下移按钮,配合 { kind: "move", direction } 协议,后续再补拖拽。

[furkancak1r]

+1 — still missing on 0.2.0-rc.2 (desktop). The QueueDock row actions are still edit / remove / steer only.

Data point from a plugin workaround: I added drag-and-drop reordering from a local client plugin (conversation.input.dock entry) — a grip at the left of each queued row (pointer drag with a drop indicator, Esc to cancel, ↑/↓ on the focused grip for keyboard). Since updateQueue has no move, the plugin rotates the affected rows' text with a series of edit calls (tail → head, reverting applied edits on failure). It works for text-only rows, but:

• rows with images/files can't be moved or crossed (edit is text-only),
• a move is several non-atomic RPCs (a row claimed by the agent mid-move needs a revert),
• the grips have to be portaled into QueueDock's DOM because rows aren't a slot.

So a native { kind: "move", targetIndex } (or direction: "up" | "down") on session.updateQueue as proposed here would make this atomic and attachment-safe. A per-row slot in QueueDock would also help plugins.