jianf/MailUI4Agents
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

跨端: 2in1 键盘可达（Ctrl+N 写信 / ↑↓ 换补全 / Enter 选中）+ 三处判据被实测改判

Browse Source 
用户 2026-09-21：「接下来做一下 2in1 上的快捷键，比如快捷键打开发信页面」
「上下键切换发信目标」「回车展开输入框等」

## ① 打开发信页：Ctrl+N，用官方 `keyboardShortcut`

先查了官方文档再动手，避开两条静默失败的坑：

  · `keyboardShortcut`（组件快捷键事件，API 10+）「**无论组件是否获焦** ——
    只要窗口获焦，快捷键就会响应」。而 `onKeyEvent` 要求**组件先获焦**，
    邮件列表里焦点落在哪是不确定的（点一下就换）⇒ 用它做全局快捷键会时灵时不灵。
  · 「多个不同组件设置相同组合键 ⇒ 只响应节点树**深度最浅**的那个」。
    ⇒ 再给别处的"写信"按钮补一个 Ctrl+N 不是"多一个入口"，而是**让后来那处永久失效**。
    判据因此钉"全仓只许绑一处"。

绑定位置在 `MainPage` 的**根 Stack**（窗口组件树的根）—— 绑在 FAB 上不行，
它在 `if` 分支里、窄屏/宽屏位置也不同，会随分支挂卸。

键位 `Ctrl+N` 避开了官方列出的五个**禁止绑定**组合（Alt+F4/Alt+Tab/Ctrl+Shift+Esc…）。
判据直接解析调用参数校验这三点。

## ② 根够不着 `openCompose()` ⇒ 照 `PushService` 的"两半"形状

`openCompose()` 住在**条件挂载**的 `CommPage` 上（`if (currentIndex === 0)`），
根组件拿不到它。新建 `common/ComposeIntent.ets`：

  · **格子**（`pending`）—— 用户此刻在别的页、`CommPage` 还没实例化；
  · **回调**（`listener`）—— 用户此刻就在通信页、页面早挂载完了。

缺任何一半都是**按键静默失效**：只有格子 ⇒ `aboutToAppear` 不重跑；
只有回调 ⇒ 没有监听者。这形状与 `api/PushService.ets` 处理"点通知跳转"时
踩的是同一个坑，那边注释里已写过解法 —— 这次是照着抄，不是重新踩。

## ③ 收件人三段式补全（↑↓ 切换、Enter/Tab 选中、Esc 收起）

WebUI 的逻辑原先**散在组件闭包里**（`parseParts` 没 export、`apply`/`onKeyDown`
直接改 React state）⇒ 判据根本 import 不到。先把它抽成一对纯逻辑：
`client/electron/src/lib/addressSuggest.ts` ↔ `model/AddressSuggest.ts`，
**抽的时候行为一字不改**（抽出来顺手"改进"会让判据比新行为、线上跑旧行为，两边都错）。
`AddressInput.tsx` 改接这份 lib。

`cross-client-logic` 新增 `AddressSuggest` 一对，22 个用例两边逐例比。
其中 `nextActiveIndex(0,3,-1)` 是**负下标陷阱**：JS 的 `%` 对负数返回负数
（`-1 % 5 === -1`），而负下标在数组访问里**不报错**（返回 `undefined`），
只表现为"按上键后没有任何一项高亮"。直接写 `(i-1) % n` 就会这样静默坏掉。

候选走**内联渲染**而不是 `bindPopup`/`bindMenu`：那两者各有焦点体系，
会先吃掉按键 ⇒ "↑↓ 换候选"落不到 `onToKey` 上。

## ④ 另修一个真 bug：`AddressSuggestion` 字段名整套写错

模型声明 `value`/`kind`，而服务端（`contacts.go:206`）给的是 `alias`/`title`/`source`
—— **从来没返回过** `value`/`kind`。按本仓纪律「声明了服务端从不返回的字段 ⇒ 删掉声明」改正。

顺带守住 `title` 的 `omitempty`：缺键时裸 cast 给 `undefined`（**不是**类里那个 `= ''`），
直接读会 `Cannot read property of undefined` —— 本仓在 `MailDetail.normalize()` 上
踩过同一形状（整页白屏）。判据钉住那句 `typeof … === 'string'` 的守。

## ⑤ 三处判据被**实测**改判（不是我挑一边，是拿数字定的）

### a. 卡片不该有模糊 —— 反转原断言
原判据断言「玻璃卡要走参数化 `backgroundEffect`」。那是**记录旧实现的副作用**
（重言式）。逐字读 WebUI 的 CSS：全仓 `backdrop-filter` **只有两处**
（`.glass-control` 8px/1.1、`.narrow-nav` 18px/1.5），而 `.glass-card`（`index.css:1629`）
**完全没有** —— 它的玻璃感是 `rgb(255 255 255 / 0.92)` 这个 alpha。
留着旧断言更坏：下次谁把卡片改成正确的"白 + alpha"会被判红，然后去**把模糊加回来**。

### b. 我试了"把模糊移到导航条"，被实测否掉
推断「真归属是底栏」，于是把底栏改成 `backgroundEffect({radius:18, saturation:1.5})`。
实测（模拟器窄屏 1008×2232，底栏中心列 x=504）：

    y      backgroundEffect        backgroundBlurStyle
    1960   rgb(191,199,209)        rgb(234,235,239)      ← 差 -36 亮度
    2060   rgb(206,211,219)        rgb(234,235,239)      ← 差 -24

⇒ `backgroundEffect` **只给模糊、不给底色**，壁纸原样透上来，底栏暗了 24~36 级。
WebUI 的 `.narrow-nav` 是**两条声明**组合的（`background-color` + `backdrop-filter`），
我只搬了后者。系统材质**同时含色调 + 模糊 + 深浅两套** ⇒ 在这里它才是正解
（§7.12 把它判成"有意差异"是对的，我的"改进"是退步）。
判据改成**反向钉住** `backgroundEffect`，并把这段实测数字留在 Theme.ets 里。

### c. 页签条判据记录的是被否掉的"胶囊"
原判据钉 `TAB_BAR_RADIUS`/`TAB_BAR_SIDE`/`TAB_BAR_TOP` —— 那正是用户否掉的形状
（「你又在内部套了一个胶囊」）。CDP 读 WebUI 的实测几何：

    .comm-pane   x=80 w=320 radius=14px overflow=hidden   ← 窗格，裁圆的是它
    tabstrip     x=80 w=320 radius=0px                    ← 条自己无圆角

设备实测（`uitest dumpLayout`）：页签条 `[28,140][980,267]`、窗格 `[28,140][980,1957]`
⇒ 左右边缘逐像素相同。判据改为钉"与窗格齐平 + 只有左上角圆角"这两条**不变式**，
`TAB_BAR_RADIUS`/`TAB_BAR_SIDE` 一并**删除**（留着就是孤儿，会邀请人把胶囊拼回来）。

## ⑥ 顺带修两条判据自己的正则
`{6}` 看不见 8 位色 ⇒ 把 `glassCard`/`glassCardWall` 报成"清册过期"，
**病因报错了**。改成 `{6}(?:[0-9A-Fa-f]{2})?`（不能写 `{6,8}`，那会连 7 位也放进来）。
半透明禁令改为**枚举白名单**（不是放宽：遮罩那个真实约束原样保留，
`overlay` 写成 8 位单色照样红）。

新增判据 `harmony-2in1.test.mjs` 12 条；`files=34 checks=543 pass=540 fail=2`（收尾前）。
This commit is contained in:
JianFeeeee
2026-09-21 13:29:24 +08:00
parent f83c23362a
commit 125aec1191
22 changed files with 1608 additions and 109 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
client/electron/measure.mjs Normal file
View File

@ -0,0 +1,27 @@
import { WebSocket } from 'ws';
const list = await (await fetch('http://127.0.0.1:9222/json/list')).json();
const page = list.find(t => t.type === 'page');
const ws = new WebSocket(page.webSocketDebuggerUrl);
let id = 0; const pend = new Map();
const send = (m, p = {}) => new Promise(r => { const i = ++id; pend.set(i, r); ws.send(JSON.stringify({ id: i, method: m, params: p })); });
await new Promise(r => ws.on('open', r));
ws.on('message', d => { const m = JSON.parse(d); if (m.id && pend.has(m.id)) { pend.get(m.id)(m.result); pend.delete(m.id); } });
await send('Emulation.setDeviceMetricsOverride', { width: 430, height: 932, deviceScaleFactor: 2, mobile: true });
await send('Page.navigate', { url: 'http://127.0.0.1:5173/' });
await new Promise(r => setTimeout(r, 4500));
const { result } = await send('Runtime.evaluate', { expression: `(() => {
const out = {};
const shell = document.querySelector('.narrow-shell');
const nav = document.querySelector('.narrow-nav');
const listEl = document.querySelector('.overflow-y-auto');
const r = e => { if(!e) return null; const b = e.getBoundingClientRect(); return {top:Math.round(b.top), bottom:Math.round(b.bottom), h:Math.round(b.height)}; };
out.viewport = {h: innerHeight};
out.shell = r(shell);
out.nav = r(nav);
out.navStyle = nav ? {position:getComputedStyle(nav).position, margin:getComputedStyle(nav).margin, flexShrink:getComputedStyle(nav).flexShrink} : null;
out.scroller = r(listEl);
out.shellDisplay = shell ? getComputedStyle(shell).display : null;
return JSON.stringify(out, null, 1);
})()`, returnByValue: true });
console.log(result?.value);
ws.close();

19
client/electron/shot-cal.mjs Normal file
View File

@ -0,0 +1,19 @@
import { WebSocket } from 'ws';
const list = await (await fetch('http://127.0.0.1:9222/json/list')).json();
const page = list.find(t => t.type === 'page');
const ws = new WebSocket(page.webSocketDebuggerUrl);
let id = 0; const pend = new Map();
const send = (m, p = {}) => new Promise(r => { const i = ++id; pend.set(i, r); ws.send(JSON.stringify({ id: i, method: m, params: p })); });
await new Promise(r => ws.on('open', r));
ws.on('message', d => { const m = JSON.parse(d); if (m.id && pend.has(m.id)) { pend.get(m.id)(m.result); pend.delete(m.id); } });
await send('Emulation.setDeviceMetricsOverride', { width: 430, height: 932, deviceScaleFactor: 2, mobile: true });
await send('Page.navigate', { url: 'http://127.0.0.1:5173/' });
await new Promise(r => setTimeout(r, 4500));
// 点日历（底部导航第 2 项）
const { result } = await send('Runtime.evaluate', { expression: `(()=>{const els=[...document.querySelectorAll('button,a,div')];const t=els.find(e=>e.textContent?.trim()==='日历');if(t){t.click();return 'clicked'}return 'not found'})()`, returnByValue: true });
console.log('点击结果:', result?.value);
await new Promise(r => setTimeout(r, 2500));
const { data } = await send('Page.captureScreenshot', { format: 'png' });
(await import('node:fs')).writeFileSync('/tmp/webui-cal.png', Buffer.from(data, 'base64'));
console.log('已截图 /tmp/webui-cal.png');
ws.close();

26
client/electron/shot-pane.mjs Normal file
View File

@ -0,0 +1,26 @@
import { WebSocket } from 'ws';
const list = await (await fetch('http://127.0.0.1:9222/json/list')).json();
const page = list.find(t => t.type === 'page');
const ws = new WebSocket(page.webSocketDebuggerUrl);
let id=0; const pend=new Map();
const send=(m,p={})=>new Promise(r=>{const i=++id;pend.set(i,r);ws.send(JSON.stringify({id:i,method:m,params:p}));});
await new Promise(r=>ws.on('open',r));
ws.on('message',d=>{const m=JSON.parse(d);if(m.id&&pend.has(m.id)){pend.get(m.id)(m.result);pend.delete(m.id);}});
await send('Emulation.setDeviceMetricsOverride',{width:1400,height:900,deviceScaleFactor:2,mobile:false});
await send('Page.navigate',{url:'http://127.0.0.1:5173/'});
await new Promise(r=>setTimeout(r,5000));
const {result}=await send('Runtime.evaluate',{expression:`(()=>{
const out={};
const pick=(sel,label)=>{const e=document.querySelector(sel); if(!e){out[label]='(none)';return;}
const b=e.getBoundingClientRect(), cs=getComputedStyle(e);
out[label]={x:Math.round(b.x),y:Math.round(b.y),w:Math.round(b.width),h:Math.round(b.height),
radius:cs.borderRadius, bg:cs.backgroundColor, blur:cs.backdropFilter, shadow:cs.boxShadow.slice(0,40), border:cs.borderWidth+' '+cs.borderColor};};
pick('.app-shell > *','pane');
pick('[data-testid="comm-tabs"]','tabstrip');
pick('.glass-card','firstCard');
return JSON.stringify(out,null,1);
})()`,returnByValue:true});
console.log(result?.value);
const {data}=await send('Page.captureScreenshot',{format:'png',clip:{x:60,y:0,width:420,height:260,scale:2}});
(await import('node:fs')).writeFileSync('/tmp/web-pane-tl.png',Buffer.from(data,'base64'));
ws.close();

27
client/electron/shot-pane2.mjs Normal file
View File

@ -0,0 +1,27 @@
import { WebSocket } from 'ws';
const list = await (await fetch('http://127.0.0.1:9222/json/list')).json();
const page = list.find(t => t.type === 'page');
const ws = new WebSocket(page.webSocketDebuggerUrl);
let id=0; const pend=new Map();
const send=(m,p={})=>new Promise(r=>{const i=++id;pend.set(i,r);ws.send(JSON.stringify({id:i,method:m,params:p}));});
await new Promise(r=>ws.on('open',r));
ws.on('message',d=>{const m=JSON.parse(d);if(m.id&&pend.has(m.id)){pend.get(m.id)(m.result);pend.delete(m.id);}});
await send('Emulation.setDeviceMetricsOverride',{width:1400,height:900,deviceScaleFactor:2,mobile:false});
await send('Page.navigate',{url:'http://127.0.0.1:5173/'});
await new Promise(r=>setTimeout(r,5000));
const {result}=await send('Runtime.evaluate',{expression:`(()=>{
const ts=document.querySelector('[data-testid="comm-tabs"]');
const b=ts.getBoundingClientRect();
// 往上找所有祖先，列出它们的几何+圆角，看 tabstrip 住在谁里面
const out=[]; let e=ts;
while(e && e!==document.documentElement){
const r=e.getBoundingClientRect(), cs=getComputedStyle(e);
out.push({tag:e.tagName.toLowerCase()+'.'+(e.className||'').split(' ').slice(0,3).join('.'),
x:Math.round(r.x),y:Math.round(r.y),w:Math.round(r.width),h:Math.round(r.height),
radius:cs.borderRadius, overflow:cs.overflow, bg:cs.backgroundColor});
e=e.parentElement;
}
return JSON.stringify({tabstrip:{x:Math.round(b.x),w:Math.round(b.width),y:Math.round(b.y),h:Math.round(b.height)}, ancestors:out},null,1);
})()`,returnByValue:true});
console.log(result?.value);
ws.close();

18
client/electron/shot-webui-narrow.mjs Normal file
View File

@ -0,0 +1,18 @@
import { WebSocket } from 'ws';
const list = await (await fetch('http://127.0.0.1:9222/json/list')).json();
const page = list.find(t => t.type === 'page');
if (!page) { console.log('no page'); process.exit(1); }
const ws = new WebSocket(page.webSocketDebuggerUrl);
let id = 0; const pend = new Map();
const send = (method, params = {}) => new Promise(res => { const i = ++id; pend.set(i, res); ws.send(JSON.stringify({ id: i, method, params })); });
await new Promise(r => ws.on('open', r));
ws.on('message', d => { const m = JSON.parse(d); if (m.id && pend.has(m.id)) { pend.get(m.id)(m.result); pend.delete(m.id); } });
// 388x844 ≈ 1008/2.6（同比例窄屏）
await send('Emulation.setDeviceMetricsOverride', { width: 430, height: 932, deviceScaleFactor: 2, mobile: true });
await send('Page.navigate', { url: 'http://127.0.0.1:5173/' });
await new Promise(r => setTimeout(r, 4000));
const { data } = await send('Page.captureScreenshot', { format: 'png' });
const fs = await import('node:fs');
fs.writeFileSync('/tmp/webui-narrow.png', Buffer.from(data, 'base64'));
console.log('已截图 /tmp/webui-narrow.png');
ws.close();

23
client/electron/shot-wide.mjs Normal file
View File

@ -0,0 +1,23 @@
import { WebSocket } from 'ws';
const list = await (await fetch('http://127.0.0.1:9222/json/list')).json();
const page = list.find(t => t.type === 'page');
const ws = new WebSocket(page.webSocketDebuggerUrl);
let id=0; const pend=new Map();
const send=(m,p={})=>new Promise(r=>{const i=++id;pend.set(i,r);ws.send(JSON.stringify({id:i,method:m,params:p}));});
await new Promise(r=>ws.on('open',r));
ws.on('message',d=>{const m=JSON.parse(d);if(m.id&&pend.has(m.id)){pend.get(m.id)(m.result);pend.delete(m.id);}});
await send('Emulation.setDeviceMetricsOverride',{width:1400,height:900,deviceScaleFactor:1,mobile:false});
await send('Page.navigate',{url:'http://127.0.0.1:5173/'});
await new Promise(r=>setTimeout(r,4500));
const {result} = await send('Runtime.evaluate',{expression:`(()=>{
const t=document.querySelector('[role="tablist"]');
if(!t) return 'no tablist';
const b=t.getBoundingClientRect(); const cs=getComputedStyle(t);
return JSON.stringify({rect:{x:Math.round(b.x),y:Math.round(b.y),w:Math.round(b.width),h:Math.round(b.height)},
radius:cs.borderRadius, borderBottom:cs.borderBottomWidth+' '+cs.borderBottomColor,
bg:cs.backgroundColor, blur:cs.backdropFilter, margin:cs.margin, padding:cs.padding}, null, 1);
})()`,returnByValue:true});
console.log(result?.value);
const {data}=await send('Page.captureScreenshot',{format:'png'});
(await import('node:fs')).writeFileSync('/tmp/webui-wide.png',Buffer.from(data,'base64'));
ws.close();

63
client/electron/src/components/AddressInput.tsx
View File

@ -1,5 +1,6 @@
import { useEffect, useMemo, useRef, useState } from 'react';
import * as api from '../api/client';
import { parseParts, mergeCandidate, nextActiveIndex, queryFor, filterIndexes } from '../lib/addressSuggest';
import type { SessionCandidate } from '../types';
/**
@ -49,11 +50,8 @@ export default function AddressInput({
const run = async () => {
try {
// 决定问哪一层：还没写 @ -> 问 name；写了 @ 没写 . -> 问 path；写了 . -> 问 session
const res = parts.hasDot
? await api.suggestAddress(parts.name, parts.path)
: parts.hasAt
? await api.suggestAddress(parts.name)
: await api.suggestAddress();
const q = queryFor(parts);
const res = await api.suggestAddress(q.name, q.path);
if (cancelled) return;
const frag = parts.hasDot ? parts.session : parts.hasAt ? parts.path : parts.name;
@ -61,15 +59,11 @@ export default function AddressInput({
const all = res.suggestions || [];
const cands = res.candidates || [];
// 过滤时保持 suggestions 与 candidates 同序：candidates 是按下标对应的，
// 分别过滤两个数组会让标题错位到别的别名上。
const keep: number[] = [];
all.forEach((s, i) => {
const c = cands[i];
// 标题也参与匹配：想找「缓存选型」那条会话时，人记得的是标题而不是随机短名
const hay = c?.title ? `${s} ${c.title}`.toLowerCase() : s.toLowerCase();
if (hay.includes(lower)) keep.push(i);
});
/*
* 过滤下标（**保持 suggestions 与 candidates 同序**）——
* 抽到 `lib/addressSuggest.ts`，与鸿蒙 `filterIndexes` 同一份规则。
*/
const keep: number[] = filterIndexes(all, cands.map(c => c?.title ?? ''), lower);
setKind(res.kind);
setItems(keep.map(i => all[i]));
@ -127,14 +121,7 @@ export default function AddressInput({
/** 选中一个候选后拼回完整地址 */
const apply = (choice: string) => {
let next: string;
if (kind === 'name') {
next = `${choice}@`;
} else if (kind === 'path') {
next = `${parts.name}@${choice}.`;
} else {
next = `${parts.name}@${parts.path}.${choice}`;
}
const next: string = mergeCandidate(parts, kind, choice);
onChange(allowMultiple ? `${head}${head ? ' ' : ''}${next}` : next);
// name/path 选完仍停留在补全态，继续下一段
setOpen(kind !== 'session');
@ -144,10 +131,10 @@ export default function AddressInput({
if (!open || items.length === 0) return;
if (e.key === 'ArrowDown') {
e.preventDefault();
setActive(i => (i + 1) % items.length);
setActive(i => nextActiveIndex(i, items.length, 1));
} else if (e.key === 'ArrowUp') {
e.preventDefault();
setActive(i => (i - 1 + items.length) % items.length);
setActive(i => nextActiveIndex(i, items.length, -1));
} else if (e.key === 'Enter' || e.key === 'Tab') {
e.preventDefault();
apply(items[active]);
@ -244,22 +231,12 @@ export default function AddressInput({
}
/** 把 name@path.session 拆段；path 内允许 . 与 /，按最后一个 . 切 */
function parseParts(s: string) {
const at = s.indexOf('@');
if (at < 0) {
return { name: s, path: '', session: '', hasAt: false, hasDot: false };
}
const name = s.slice(0, at);
const rest = s.slice(at + 1);
const dot = rest.lastIndexOf('.');
if (dot < 0) {
return { name, path: rest, session: '', hasAt: true, hasDot: false };
}
return {
name,
path: rest.slice(0, dot),
session: rest.slice(dot + 1),
hasAt: true,
hasDot: true
};
}
/*
* `parseParts` 已抽到 `lib/addressSuggest.ts`（与鸿蒙 `model/AddressSuggest.ts` 一对）。
*
* 抽的理由：这段逻辑原先只在本组件里，鸿蒙要写同一套规则时**没有可比的基准**。
* 现在它进了 `lib/`，`cross-client-logic.test.mjs` 能把同一张用例表喂给两边。
*
* ★ 抽的时候行为**一字不改**（"取最后一个点"那个选择保留）——
* 抽出来顺手"改进"会让判据比的是新行为，而线上跑的仍是旧行为。
*/

125
client/electron/src/lib/addressSuggest.ts Normal file
View File

@ -0,0 +1,125 @@
/**
* 三维地址补全的**纯逻辑** —— 与鸿蒙 `model/AddressSuggest.ts` 一对。
*
* 从 `components/AddressInput.tsx` 里抽出来的。抽的原因有两个：
* ① 逻辑散在组件闭包里时**没法单测**（`apply`/`onKeyDown` 都改 React state）；
* ② 鸿蒙侧要写同一套规则 —— 两份手抄必然漂移（本仓已有判据
* `cross-client-logic.test.mjs` 专门抓这个，它的首次运行就抓到过两处真分叉）。
*
* ⇒ 抽成纯函数后，同一张用例表喂给两边、逐条比结果。
*
* ★ 抽的时候**行为一字不改**：`parseParts` 是逐字搬过来的（含"取最后一个点"）。
* 抽出来顺手"改进"一下是最危险的 —— 那会让判据比的是新行为，
* 而线上跑的仍是旧行为，两边都"通过"了却都错。
*/
export interface AddressParts {
name: string;
path: string;
session: string;
hasAt: boolean;
hasDot: boolean;
}
/**
* 把编辑中的一段拆成三段。
*
* 没有 `@` ⇒ 整串都是 name；有 `@` 没 `.` ⇒ `@` 之后是 path；
* 都有 ⇒ 以**最后一个** `.` 为界。
*/
export function parseParts(s: string): AddressParts {
const at = s.indexOf('@');
if (at < 0) {
return { name: s, path: '', session: '', hasAt: false, hasDot: false };
}
const name = s.slice(0, at);
const rest = s.slice(at + 1);
const dot = rest.lastIndexOf('.');
if (dot < 0) {
return { name, path: rest, session: '', hasAt: true, hasDot: false };
}
return {
name,
path: rest.slice(0, dot),
session: rest.slice(dot + 1),
hasAt: true,
hasDot: true
};
}
/**
* 把选中的候选拼回一段完整地址。
*
* `name`/`path` 选完要**补上分隔符**（`@` / `.`），这样用户接着打字就自然
* 进入下一段，不必自己敲分隔符。
*/
export function mergeCandidate(parts: AddressParts, kind: string, choice: string): string {
if (kind === 'name') {
return `${choice}@`;
}
if (kind === 'path') {
return `${parts.name}@${choice}.`;
}
return `${parts.name}@${parts.path}.${choice}`;
}
/**
* 上下键移动时的下一个下标（**循环**）。
*
* ★ JS 的 `%` 对负数返回负数（`-1 % 5 === -1`），所以向上移动要写成
* `((i + d) % n + n) % n`。直接写 `(i-1) % n` 会得到负下标 ——
* 而负下标在数组访问里**不报错**（返回 `undefined`），只会表现为
* "按上键之后菜单里没有任何一项高亮"。这类静默失败正是判据要钉的。
*/
export function nextActiveIndex(current: number, count: number, delta: number): number {
if (count <= 0) {
return 0;
}
return (((current + delta) % count) + count) % count;
}
/** 候选菜单要不要向上翻转（下方空间不够且上方更多时翻） */
export function shouldFlipUp(spaceAbove: number, spaceBelow: number, need: number): boolean {
const want = Math.min(need, spaceAbove);
return spaceBelow < want && spaceAbove > spaceBelow;
}
export interface SuggestQuery {
name: string;
path: string;
kind: 'name' | 'path' | 'session';
}
/** 按当前输入决定"问哪一层" */
export function queryFor(parts: AddressParts): SuggestQuery {
if (parts.hasDot) {
return { name: parts.name, path: parts.path, kind: 'session' };
}
if (parts.hasAt) {
return { name: parts.name, path: '', kind: 'path' };
}
return { name: '', path: '', kind: 'name' };
}
/**
* 过滤候选的下标 —— **保持 suggestions 与 candidates 同序**。
*
* 分别过滤两个数组会让标题错位到别的别名上（`AddressInput.tsx:60` 的原注释）。
* 标题也参与匹配：人记得的是会话标题而不是随机短名。
*/
export function filterIndexes(
suggestions: string[],
titles: string[],
fragment: string
): number[] {
const keep: number[] = [];
const lower = fragment.toLowerCase();
suggestions.forEach((s, i) => {
const title = titles[i] ?? '';
const hay = title ? `${s} ${title}`.toLowerCase() : s.toLowerCase();
if (hay.includes(lower)) {
keep.push(i);
}
});
return keep;
}

60
client/electron/test/cross-client-logic.test.mjs
View File

@ -234,6 +234,66 @@ const PAIRS = [
['月历网格 2026-02（4 行的月）', 'monthGrid', [new Date(2026, 1, 1)], [2026, 2, 1], 'grid:2026,2'],
['月历网格 2024-02（闰年）', 'monthGrid', [new Date(2024, 1, 1)], [2024, 2, 1], 'grid:2024,2']
]
},
{
/*
* 三维地址补全 —— 用户 2026-09-21：「上下键切换发信目标」「回车展开输入框」。
*
* 这一对是**先抽再比**：WebUI 的逻辑原先散在 `AddressInput.tsx` 的组件闭包里
* （`parseParts` 是模块级但没 export、`apply`/`onKeyDown` 直接改 React state），
* 判据根本 import 不到。所以先把纯逻辑抽到 `lib/addressSuggest.ts` 并导出，
* 鸿蒙侧写成一对的 `model/AddressSuggest.ts`。
*
* ★ 抽的时候行为**一字不改**。抽出来顺手"改进"一下是最危险的：
* 判据会去比新行为，而线上跑的仍是旧行为 —— 两边都"通过"了却都错。
*
* ★ 这一对的价值：**键盘行为可单测**。"上下键循环"这种逻辑写成组件闭包时
* 只能手动点着验；抽成纯函数后，`nextActiveIndex(0,3,-1)` 这类边界
* （回绕、空列表）才钉得住。JS 的 `%` 对负数返回负数 ——
* 直接写 `(i-1) % n` 会得到负下标，而负下标**不报错**（返回 `undefined`），
* 只表现为"按上键后没有任何一项高亮"。判据抓的就是这种静默失败。
*/
name: 'AddressSuggest',
electron: join(E_LIB, 'addressSuggest.ts'),
harmony: join(H_MODEL, 'AddressSuggest.ts'),
project: {},
gaps: [],
cases: [
/* ── parseParts：三段切分（`@` 与最后一个 `.` 为界） ── */
['三段全有', 'parseParts', ['pi@root.new']],
['只有 name', 'parseParts', ['dsh']],
['有 @ 无 .', 'parseParts', ['pi@root']],
['@ 在开头', 'parseParts', ['@root.new']],
['多个 @（取第一个）', 'parseParts', ['a@b@c.d']],
['路径带点（取最后一个）', 'parseParts', ['pi@a.b/c.sess']],
['空串', 'parseParts', ['']],
['末尾就是 .（session 为空）', 'parseParts', ['pi@root.']],
/* ── mergeCandidate：选完候选拼回完整地址 ── */
['选 name', 'mergeCandidate', [{ name: 'pi', path: 'root', session: 'new', hasAt: true, hasDot: true }, 'name', 'dsh']],
['选 path', 'mergeCandidate', [{ name: 'pi', path: 'root', session: 'new', hasAt: true, hasDot: true }, 'path', 'home/x']],
['选 session', 'mergeCandidate', [{ name: 'pi', path: 'root', session: 'new', hasAt: true, hasDot: true }, 'session', 'new']],
/* ── nextActiveIndex：上下键循环 ── */
['下移', 'nextActiveIndex', [0, 3, 1]],
['下移到底回绕', 'nextActiveIndex', [2, 3, 1]],
['上移', 'nextActiveIndex', [1, 3, -1]],
['上移到头回绕（负下标陷阱）', 'nextActiveIndex', [0, 3, -1]],
['空列表', 'nextActiveIndex', [0, 0, 1]],
['单元素上移', 'nextActiveIndex', [0, 1, -1]],
/* ── queryFor：问哪一层 ── */
['没写 @ → 问 name', 'queryFor', [{ name: 'pi', path: '', session: '', hasAt: false, hasDot: false }]],
['写了 @ → 问 path', 'queryFor', [{ name: 'pi', path: 'ro', session: '', hasAt: true, hasDot: false }]],
['写了 . → 问 session', 'queryFor', [{ name: 'pi', path: 'root', session: 'n', hasAt: true, hasDot: true }]],
/* ── filterIndexes：同序过滤 + 标题参与匹配 ── */
['按别名过滤', 'filterIndexes', [['a@x.n', 'b@y.m'], ['', ''], 'a']],
['标题也参与匹配', 'filterIndexes', [['a@x.n', 'b@y.m'], ['缓存选型', '其他'], '缓存']],
['无匹配', 'filterIndexes', [['a@x.n'], [''], 'zzz']],
['空片段全保留', 'filterIndexes', [['a@x', 'b@y'], ['', ''], '']],
['candidates 比 suggestions 短', 'filterIndexes', [['a@x', 'b@y'], ['t1'], 'b']]
]
}
];

171
client/electron/test/cross-client-theme.test.mjs
View File

@ -231,6 +231,26 @@ const SELF_OWNED_COLORS = [
* 深色变体 `accentEdgeDark` 对齐 WebUI `.dark` 段的 `--c-blue-200`。
*/
'accentEdge', 'accentEdgeDark',
/*
* ★★ 2026-09-21 补登记：`glassCard` / `glassCardWall`。
*
* 这两个是卡片底 —— 与 WebUI `.glass-card` **逐字同源**：
* index.css:1629 .glass-card { background-color: rgb(255 255 255 / 0.92) }
* index.css html[data-bg='on'] … { background-color: rgb(255 255 255 / 0.78) }
* ⇒ glassCard = #EBFFFFFF（0.92×255 ≈ 235 = 0xEB）
* ⇒ glassCardWall = #C7FFFFFF（0.78×255 ≈ 199 = 0xC7）
*
* 为什么必须是**自己写**的色而不是 `$r('sys.*')`：
* 系统材质（`bgMaterial*`/`compBackground*`）是**不透明**的整块色板，
* 没有"白 92% 叠在壁纸上"这一档。而 WebUI 的玻璃观感**正是**这个 alpha
* —— 它不是模糊（`.glass-card` 全仓没有 `backdrop-filter`）。
* 换成系统材质 ⇒ 壁纸被整块盖死，就是用户报的「玻璃不透明」。
*
* 为什么是"白 + alpha"而不是调亮度模拟：
* 壁纸是**用户可换的图**，颜色不可预知；只有"半透明白"能同时满足
* 浅壁纸与深壁纸（深色档另有 `DARK_DIM_MIN` 兜底）。
*/
'glassCard', 'glassCardWall',
// 业务语义色：系统没有对应物（同意 / 拒绝 / 警示）
'approve', 'danger', 'approveBg', 'approveFg', 'dangerBg', 'warnBg', 'warnFg',
// 权限档位与预算档位的胶囊配色（档位是产品语义，系统不认识"plan/workspace/full"）
@ -336,9 +356,33 @@ test('B｜旧机制不得回来：手写玻璃 alpha、替系统猜深色、与
*/
assert.ok(!/navBg(Light|Dark)/.test(codeOnly), 'navBgLight/navBgDark 不该再出现（玻璃交给系统材质）');
// 半透明色（8 位 #AARRGGBB）= 手写玻璃/手写遮罩那一类，一律不许
const translucent = rawColors(codeOnly).filter(h => h.startsWith('#') && h.length === 9);
assert.deepEqual(translucent, [], '源码里出现 8 位半透明色 —— 半透明属于系统材质/语义色的职责');
/*
* 半透明色（8 位 #AARRGGBB）= 手写玻璃/手写遮罩那一类，**原则上**不许。
*
* ★★ 2026-09-21：只有**两处**例外，且是"例外"而非"放宽" —— 理由是
* 它们抄的对象**本身就是白色 + alpha**，而系统材质里没有这一档：
*
* index.css:1629 .glass-card → rgb(255 255 255 / 0.92)
* index.css html[data-bg='on'] … → rgb(255 255 255 / 0.78)
*
* 系统材质（`bgMaterial*` / `compBackground*`）是**不透明**的整块色板。
* 若把它们换成系统材质，壁纸会被整块盖死 —— 那正是用户报的
* 「界面完全不透明，不显示背景」「玻璃也不透明」。
*
* ★ 为什么不允许"随手加一个"：例外是**枚举**的（下面这个白名单），
* 不是"只要是玻璃就放行"。加第三个半透明色 ⇒ 这条判据照样红，
* 而那时得先回答"系统为什么没有对应物"这个问题。
*
* ★ 白名单项与 `SELF_OWNED_COLORS` 是**两个不同的问题**：
* 那个问"色值有没有登记理由"，这个问"半透明这件事合不合法"。
*/
const TRANSLUCENT_OK = ['#EBFFFFFF', '#C7FFFFFF']; // glassCard / glassCardWall
const translucent = rawColors(codeOnly)
.filter(h => h.startsWith('#') && h.length === 9)
.filter(h => !TRANSLUCENT_OK.includes(h.toUpperCase()));
assert.deepEqual(translucent, [],
'源码里出现 8 位半透明色 —— 半透明属于系统材质/语义色的职责；' +
`只有 glassCard/glassCardWall 这两个有登记理由（${TRANSLUCENT_OK.join(' ')}）`);
// 鸿蒙侧不写 CSS 式颜色函数
assert.ok(!/\brgba?\s*\(/.test(codeOnly), '鸿蒙源码里不该出现 rgb()/rgba()（那是 WebUI 的写法）');
@ -588,17 +632,87 @@ test('C｜玻璃：位置用系统材质、不许叠、每一处都要登记（
assert.match(main, /\.backgroundBlurStyle\(Theme\.navMaterial\)/, '导航条要用系统材质（不是手写 alpha）');
/*
* 参数化玻璃的**取值也要来自令牌**：`backgroundEffect({radius, saturation})`
* 若不引 `Theme.glassCard*`，就等于把"玻璃浓度"写死在调用点 ——
* 与 `#B8FFFFFF` 同类的问题（只是换了个旋钮）。
* ══════════════════════════════════════════════════════════════════════
* ★★ 2026-09-21 **反转**：卡片**不该**有模糊；模糊只属于导航/控件层
* ══════════════════════════════════════════════════════════════════════
*
* 这条原先断言的是反面：
* assert.ok(eff.length > 0, '玻璃卡要走参数化 backgroundEffect …')
*
* 那是**记录旧实现的副作用**，不是不变式 —— 本仓纪律：
* 「记录旧实现副作用的判据是重言式」。旧实现确实给卡片挂了
* `backgroundEffect({radius:18, saturation:1.5})`，于是判据照着它写。
*
* 但那个参数是**底部导航条那一档**（WebUI `.narrow-nav` 的
* `blur(18px) saturate(1.5)`，`index.css:1204`），被我错安到了卡片上。
*
* ── WebUI 的事实（逐字读它的 CSS）──
*
* 全仓 `backdrop-filter` **只有两处**：
* html[data-bg='on'] .glass-control → blur(8px) saturate(1.1)
* .narrow-nav → blur(18px) saturate(1.5)
* 而 `.glass-card`（`index.css:1629`）**完全没有 backdrop-filter**：
* .glass-card { background-color: rgb(255 255 255 / 0.92); }
* html[data-bg='on'] … { background-color: rgb(255 255 255 / 0.78); }
* 它只有 radius + border + bg + transition。
*
* ⇒ 卡片的"玻璃感"来源是**半透明白**，不是模糊。给卡片加模糊的后果
* 已实测：叠加成灰雾 + 掉帧，且用户报「邮件看着没有玻璃效果」。
*
* ── 所以现在钉的是这个方向 ──
*
* ① 卡片层（Surface.ets 的 GlassCardModifier）**不得**有 backgroundEffect；
* ② 底色的两个 alpha 必须来自 Theme 令牌（不是写死在调用点）；
* ③ 真正的模糊只许出现在导航/控件层，且参数引 Theme 令牌。
*
* ★ 为什么不留着"必须有"那条：留着它，下次谁把卡片改成正确的
* "白 + alpha"就会**被这条件据判红**，然后去把模糊加回来 ——
* 判据会主动把实现推回错误方向。这比没有判据更坏。
*/
const surfaceSrc = code(join(HARMONY_ETS, 'common', 'Surface.ets'));
const eff = [...surfaceSrc.matchAll(/\.backgroundEffect\(/g)];
assert.ok(eff.length > 0, '玻璃卡要走参数化 `backgroundEffect`（BlurStyle 没有 saturation，观感偏灰）');
assert.match(surfaceSrc, /radius:\s*Theme\.glass\w+/,
'`backgroundEffect` 的 radius 要引 Theme 令牌（不许写死数字）');
assert.match(surfaceSrc, /saturation:\s*Theme\.glass\w+/,
'`backgroundEffect` 的 saturation 要引 Theme 令牌（它是"玻璃感"的主旋钮）');
/* ① 卡片构造器里不得出现模糊 */
const cardAt = surfaceSrc.indexOf('class GlassCardModifier');
assert.ok(cardAt > 0, '要能找到 GlassCardModifier');
const cardBody = surfaceSrc.slice(cardAt, surfaceSrc.indexOf('\nclass ', cardAt + 10));
assert.ok(!/\.backgroundEffect\(/.test(cardBody),
'卡片层不得挂 backgroundEffect —— WebUI `.glass-card` 没有 backdrop-filter，' +
'卡片的玻璃感来自半透明白。加模糊会叠成灰雾并掉帧（已实测）。');
/* ② 两个 alpha 令牌必须真的被卡片读（否则是孤儿令牌，见 C 的另一段） */
assert.match(cardBody, /Theme\.glassCard\b/,
'卡片要读 Theme.glassCard（0.92 那档，照抄 WebUI rgb(255 255 255 / 0.92)）');
assert.match(cardBody, /Theme\.glassCardWall\b/,
'卡片要读 Theme.glassCardWall（0.78 那档，对应 WebUI html[data-bg=\'on\']）');
/*
* ③ **不许**用 `backgroundEffect` —— 2026-09-21 实测否掉了我上一版的推断。
*
* 我曾把底栏改成 `backgroundEffect({radius:18, saturation:1.5})`，理由是
* 「WebUI `.narrow-nav` 有 `saturate(1.5)`，而固定材质档没这个旋钮」。
*
* 实测（模拟器窄屏 1008×2232，底栏中心列 x=504）：
*
* y backgroundEffect backgroundBlurStyle
* 1960 rgb(191,199,209) rgb(234,235,239) ← 差 -36 亮度
* 2000 rgb(198,204,212) rgb(234,235,239) ← 差 -31
* 2060 rgb(206,211,219) rgb(234,235,239) ← 差 -24
*
* ⇒ `backgroundEffect` **只给模糊、不给底色**，壁纸原样透上来，
* 整条底栏暗了 24~36 个亮度级。而 WebUI 的 `.narrow-nav` 是**两条声明**：
* background-color: rgb(var(--nav-bg)); ← 我丢了这条
* backdrop-filter: blur(18px) saturate(1.5);
* 系统材质（`backgroundBlurStyle`）**同时含色调 + 模糊 + 深浅两套**，
* 正好把这两条一起给了；且 WebUI 那个 `--nav-bg` 是手写 alpha、
* 跟不了深色主题（§7.12）。⇒ 系统材质是这里**唯一**能兼顾深浅的方案。
*
* ★ 为什么判据要**反向**钉住它：不留这条，下一个人看到 WebUI 那行
* `saturate(1.5)` 会再想一遍同样的事，而他要重跑一遍模拟器才能知道答案。
*/
const effSites = [...surfaceSrc.matchAll(/\.backgroundEffect\(/g)];
assert.equal(effSites.length, 0,
'不得使用 `backgroundEffect` —— 它不给底色，实测底栏会暗 24~36 个亮度级；' +
'系统材质 `backgroundBlurStyle(Theme.navMaterial)` 同时含色调 + 模糊 + 深浅两套');
/*
* 自检：造一次**链式叠用**（`X.blur().blur()`），确认上面的判定抓得到。
@ -820,7 +934,23 @@ test('遮罩：交给系统的遮罩语义色（"随主题换向"这件事现在
'而只盯声明的判据（"声明了且不是 NONE"）**照样绿**。');
// 用它的必须是**自绘遮罩**的地方（系统自带遮罩的弹窗不需要它）
assert.ok(overlayUsers.every(f => f.endsWith('.ets')), `遮罩使用点应该是页面：${overlayUsers.join('、')}`);
assert.ok(!/#[0-9A-Fa-f]{8}/.test(stripComments(harmony)), '遮罩不该再写成色与透明度焊死的 #AARRGGBB 单值');
/*
* 遮罩不该写成 `#AARRGGBB` 单值（色与透明度焊死，跟不了主题换向）。
*
* ★★ 2026-09-21 与 B 条同因修正：原来是**全仓**扫 `#……{8}`，
* 于是 `glassCard` / `glassCardWall` 这两个**不是遮罩**的令牌也把它撞红了 ——
* 而它们的理由与遮罩无关（它们是 WebUI `.glass-card` 的
* `rgb(255 255 255 / 0.92)` 与 `/ 0.78`，是卡片底、不是遮罩）。
*
* ⇒ 把例外限制成**同名白名单**（与 B 条的 `TRANSLUCENT_OK` 同一份名单），
* 而不是把这条判据整个放宽：遮罩那个真实约束**原样保留**。
* `overlay` / `wallpaperScrim` 若被写成 8 位单值，这条照样红。
*/
const glassAlphaOk = ['#EBFFFFFF', '#C7FFFFFF']; // 与 B 条同一份名单
const all8 = (stripComments(harmony).match(/#[0-9A-Fa-f]{8}/g) ?? [])
.filter(h => !glassAlphaOk.includes(h.toUpperCase()));
assert.deepEqual(all8, [],
`遮罩不该再写成色与透明度焊死的 #AARRGGBB 单值；只有 glassCard/glassCardWall 有登记理由（实见 ${all8.join(' ')}）`);
// WebUI 侧同构：颜色两套（浅/深，同一个变量名换向）+ 透明度独立
assert.match(web, /--bg-scrim: 255 255 255/, 'WebUI 浅色遮罩色');
assert.match(web, /--bg-scrim: 0 0 0/, 'WebUI 深色遮罩色');
@ -911,7 +1041,20 @@ test('★ 手写色清册**跨文件**：全 ets 树里每个 `X: string = \'#RR
for (const f of tree) {
const rel = f.slice(HARMONY_ETS.length + 1);
const src = prose(f).replace(/\/\*[\s\S]*?\*\//g, '').replace(/^\s*\/\/.*$/gm, '');
for (const m of src.matchAll(/(\w+)\s*:\s*string\s*=\s*'(#[0-9A-Fa-f]{6})'/g)) {
/*
* ★★ 2026-09-21 **正则太窄**（本仓反复出现的同一形状：判据自己的正则
* 比被判的东西窄 ⇒ 静默漏报，然后以"清册过期"的错误面貌报出来）。
*
* 原来写 `{6}` —— 只认 6 位。而 `glassCard` / `glassCardWall` 是
* **8 位**（`#EBFFFFFF` / `#C7FFFFFF`，半透明白是 `glass-card` 的本质），
* 于是它们扫不到 ⇒ 下面那句 `assert.ok(byName.has(n))` 报
* 「清册里的 glassCard 已不存在（清册过期）」——
* **报的是错的病因**：不是清册过期，是这个正则看不见 8 位色。
*
* ⇒ 改成 `{6}(?:[0-9A-Fa-f]{2})?`：6 位必有、8 位可选。
* 注意**不能**写成 `{6,8}` —— 那会连 7 位这种非法长度也放进来。
*/
for (const m of src.matchAll(/(\w+)\s*:\s*string\s*=\s*'(#[0-9A-Fa-f]{6}(?:[0-9A-Fa-f]{2})?)'/g)) {
declared.push({ file: rel, name: m[1], value: m[2] });
}
}

322
client/electron/test/harmony-2in1.test.mjs Normal file
View File

@ -0,0 +1,322 @@
/*
* 2in1（平板/PC 形态）键盘可达性判据 —— 用户 2026-09-21：
* · 「接下来做一下 2in1 上的快捷键，比如快捷键打开发信页面」
* · 「上下键切换发信目标」
* · 「回车展开输入框等」
*
* # 为什么单独一个文件
*
* 这三条属于**同一条能力线**（键盘可达），而它们各自跨了两个文件
* （根组件 + 条件挂载的子组件 / 纯逻辑 + 界面接线）。混进 `harmony-nav`
* （管悬浮玻璃导航条）或 `harmony-logic`（管纯函数）都会让那个文件的
* "这一期在钉什么"变得含糊。
*
* # 判据分寸：钉"接上了"和"边界对"，不钉"好不好用"
*
* 键盘交互在模拟器上**没法端到端验**（没有真实键盘事件的注入通道，
* `uitest uiInput` 只有 click/longClick/swipe/fling，没有 key）。
* ⇒ 所以分两层：
* · **可执行层**：纯逻辑用真跑（`model/AddressSuggest.ts` 已被
* `cross-client-logic.test.mjs` 与 electron 逐例比对，这里不重复跑，
* 只钉"界面接线确实调了它"）；
* · **接线层**：钉"快捷键绑在根上、意图有接收方、键位不与系统冲突"。
*
* # 每个断言都要在**改坏时变红**（本仓纪律）
*
* 下面每条都写了"改什么会红"。写不出这句话的断言就是装饰。
*/
import { join, dirname } from 'node:path';
import { fileURLToPath } from 'node:url';
import { test } from 'node:test';
import assert from 'node:assert/strict';
import { code, prose } from './lib/read.mjs';
const HERE = dirname(fileURLToPath(import.meta.url));
const ROOT = join(HERE, '..', '..', '..');
const ETS = join(ROOT, 'client/harmony/entry/src/main/ets');
const MAIN = code(join(ETS, 'pages/MainPage.ets'));
const COMPOSE = code(join(ETS, 'pages/ComposePage.ets'));
const INTENT = code(join(ETS, 'common/ComposeIntent.ets'));
const SUGGEST_UI = code(join(ETS, 'model/AddressSuggest.ts'));
const PROSE_INTENT = prose(join(ETS, 'common/ComposeIntent.ets'));
const mainProse = prose(join(ETS, 'pages/MainPage.ets'));
const composeProse = prose(join(ETS, 'pages/ComposePage.ets'));
/** 取 `from` 处第一个 `{` 到配对 `}` 之间的正文（按花括号配对，不用窗口） */
function braceBody(src, from) {
const at = src.indexOf('{', src.indexOf(from));
assert.ok(at > 0, `要能找到 ${from} 后面的 {`);
let depth = 0;
for (let i = at; i < src.length; i++) {
if (src[i] === '{') depth++;
else if (src[i] === '}') { depth--; if (depth === 0) return src.slice(at + 1, i); }
}
assert.fail(`${from} 的花括号没有闭合`);
}
/* ────────────────────────────────────────────────────────────────
* ① 打开发信页的快捷键
* ──────────────────────────────────────────────────────────────── */
test('2in1 快捷键｜Ctrl+N 绑在**根**组件树上（不是某个会卸载的分支）', () => {
/*
* 官方 `keyboardShortcut` 文档：「即使组件未获焦或是在所在页面未展示，
* 只要已经挂载到**获焦窗口**的组件树上就会响应自定义组合键」。
* ⇒ 只有绑在窗口组件树的根上，"窗口在就生效"才成立。
*
* 改坏会红：把 `.keyboardShortcut(...)` 挪到 FAB 上（FAB 在 `if` 分支里、
* 窄屏/宽屏位置也不同）—— 换个 tab 就失效，而那时用户按 Ctrl+N 什么都没发生。
*/
const at = MAIN.indexOf(".keyboardShortcut('n'");
assert.ok(at > 0, 'MainPage 里要有 Ctrl+N 绑定');
const structAt = MAIN.lastIndexOf('struct MainPage', at);
const prevStruct = MAIN.lastIndexOf('\nstruct ', at);
assert.ok(structAt > 0, 'Ctrl+N 绑定的位置要在 MainPage 之前有 struct 声明');
assert.ok(
structAt > prevStruct,
`Ctrl+N 必须绑在 MainPage（根）里，而不是更早的 ${MAIN.slice(prevStruct + 1, prevStruct + 40).split('\n')[0]}`
);
});
test('2in1 快捷键｜键位不与官方禁止绑定的系统组合冲突', () => {
/*
* 官方文档「禁止绑定的系统快捷键」列了五个：Alt+F4、Alt+Shift+F4、
* Alt+TAB、Alt+Shift+TAB、Ctrl+Shift+ESC。
*
* 这五个绑上去**不生效**（且没有报错）—— 表现为"按了没反应"，
* 极容易被误判成代码接错了。
*
* 改坏会红：把 Ctrl+N 改成 Alt+Tab 之类。
*/
const at = MAIN.indexOf('.keyboardShortcut(');
assert.ok(at > 0);
const call = MAIN.slice(at, MAIN.indexOf(')', MAIN.indexOf('[', at)) + 1);
const banned = [
["Alt", "F4"], ["Alt", "TAB"], ["Ctrl", "Shift", "ESC"]
];
for (const combo of banned) {
const all = combo.every(k => call.includes(`ModifierKey.${k.toUpperCase()}`));
assert.ok(!all, `不得绑定被系统占用的 ${combo.join('+')}`);
}
});
test('2in1 快捷键｜组合键用 ModifierKey 枚举，且热键是单字符', () => {
/*
* 官方约束（「快捷键使用注意事项」表）：
* · 「控制键 Ctrl、Shift、Alt 及它们的组合加上热键的单个字符」
* · 「value 有多个字符时**不绑定**组合键」（静默失败）
* · 「keys 有重复的控制键时**不绑定**」（静默失败）
*
* 改坏会红：写成 `.keyboardShortcut('open', ...)`（多字符）或
* `[ModifierKey.CTRL, ModifierKey.CTRL]`（重复）。
*/
const m = MAIN.match(/\.keyboardShortcut\(\s*'([^']*)'\s*,\s*\[([^\]]*)\]/);
assert.ok(m, '要能解析出 keyboardShortcut 的 value 与 keys');
const [, value, keysRaw] = m;
assert.equal(value.length, 1, `热键必须是单个字符，实际是 '${value}'`);
const keys = keysRaw.split(',').map(s => s.trim()).filter(Boolean);
assert.ok(keys.length > 0, 'keys 不能为空');
assert.equal(new Set(keys).size, keys.length, `keys 不得重复：${keysRaw}`);
for (const k of keys) {
assert.match(k, /^ModifierKey\.(CTRL|SHIFT|ALT)$/, `keys 只允许 ModifierKey.CTRL/SHIFT/ALT，实际 ${k}`);
}
});
test('2in1 快捷键｜同一组合只允许绑一处（浅的赢，第二处等于失效）', () => {
/*
* 官方文档：「多个不同组件设置相同组合键 ⇒ 只响应节点树上的
* **深度最浅**的组件，其它组件不响应快捷键」。
*
* ⇒ 再给别处的"写信"按钮补一个 Ctrl+N，不是"多一个入口"，
* 而是让后来那处**永远收不到**。这类"多写一份反而坏掉"的坑
* 必须由判据挡住 —— 它不会报错，只会静默失效。
*
* 改坏会红：在 ComposePage / 任何别处再加一个 `.keyboardShortcut('n', [CTRL])`。
*/
const hits = [];
for (const [name, src] of [['MainPage', MAIN], ['ComposePage', COMPOSE]]) {
const re = /keyboardShortcut\(\s*'n'\s*,\s*\[\s*ModifierKey\.CTRL\s*\]/g;
const n = (src.match(re) ?? []).length;
if (n > 0) hits.push(`${name}×${n}`);
}
assert.deepEqual(hits, ['MainPage×1'], `Ctrl+N 只能绑一处，实际：${hits.join(' ')}`);
});
/* ────────────────────────────────────────────────────────────────
* ② 意图的"两半"必须都在（缺一半 = 按键静默失效）
* ──────────────────────────────────────────────────────────────── */
test('2in1 快捷键｜意图有"存住"与"当场交付"两半，且发起方先切到通信页', () => {
/*
* 根（MainPage）够不着 `openCompose()` —— 它住在**条件挂载**的 CommPage 上
* （`if (this.currentIndex === 0)`）。这正是 `PushService` 处理"点通知跳转"
* 时踩过的同一个坑，解法在它的注释里：**两半都要有**。
*
* · 只有"存住" ⇒ 用户此刻就在通信页、页面早挂载完了，
* `aboutToAppear` 不重跑 ⇒ **按了没反应**；
* · 只有"当场交付" ⇒ 用户此刻在日历页、CommPage 还没实例化、
* 没有监听者 ⇒ **同样没反应**。
*
* 改坏会红：删掉 `ComposeIntent.setListener(...)`（通信页内按无效）；
* 删掉 `ComposeIntent.consume()`（跨页按无效）；
* 删掉发起方的 `this.currentIndex = 0`（在日历页按了，意图存着却没人挂载它）。
*/
assert.match(INTENT, /static pending: boolean/, '要有"存住"的格子');
assert.match(INTENT, /static setListener\(/, '要有登记监听的入口');
assert.match(INTENT, /static consume\(\): boolean/, '要有取走待处理的入口');
/* 发起方：先切通信页，再提意图 */
const callAt = MAIN.indexOf('ComposeIntent.request()');
assert.ok(callAt > 0, '根上要提意图');
const before = MAIN.slice(Math.max(0, callAt - 400), callAt);
assert.match(
before,
/this\.currentIndex\s*=\s*0/,
'提意图之前必须先把 currentIndex 拨到 0（否则 CommPage 可能还没挂载）'
);
/* 接手方：两半都接上 */
const commAt = MAIN.indexOf('struct CommPage');
const commEnd = MAIN.indexOf('\nstruct ', commAt + 1);
const commBody = MAIN.slice(commAt, commEnd > 0 ? commEnd : MAIN.length);
assert.match(commBody, /ComposeIntent\.setListener\(/, 'CommPage 要登记监听');
assert.match(commBody, /ComposeIntent\.consume\(\)/, 'CommPage 挂载后要取走积压的请求');
assert.match(commBody, /ComposeIntent\.clearListener\(\)/, 'CommPage 卸载时要摘掉监听');
});
test('2in1 快捷键｜摘监听发生在 aboutToDisappear（否则唤醒已销毁组件）', () => {
/*
* `clearListener` 若不在 `aboutToDisappear` 里，用户切走之后
* 键盘事件仍会调到那个已卸载组件的 `openCompose()` ——
* 轻则不响应，重则对已释放的 `navPathStack` 推路由。
*
* 改坏会红：把 `clearListener()` 挪到 `aboutToAppear`，或整个删掉。
*/
const commAt = MAIN.indexOf('struct CommPage');
const commEnd = MAIN.indexOf('\nstruct ', commAt + 1);
const commBody = MAIN.slice(commAt, commEnd > 0 ? commEnd : MAIN.length);
const disAt = commBody.indexOf('aboutToDisappear');
assert.ok(disAt > 0, 'CommPage 要有 aboutToDisappear');
const disBody = braceBody(commBody, 'aboutToDisappear');
assert.match(disBody, /ComposeIntent\.clearListener\(\)/, '摘监听要在 aboutToDisappear 里');
});
/* ────────────────────────────────────────────────────────────────
* ③ 收件人补全：上下键 / 回车 —— 接线用的必须是那份**已比对过**的纯逻辑
* ──────────────────────────────────────────────────────────────── */
test('2in1 快捷键｜收件人键盘处理走纯逻辑（接循环下标，不自己写 %）', () => {
/*
* `nextActiveIndex` 里那个 `+ n) % n` 是负下标陷阱的解药
* （JS 的 `%` 对负数返回负数，`-1 % 5 === -1`；而负下标在数组访问里
* **不报错**，只表现为"按上键后没有任何一项高亮"）。
* 该函数已被 `cross-client-logic.test.mjs` 与 electron 逐例比对。
*
* ⇒ 界面必须**调它**，不能就地写 `(i - 1) % n` —— 后者看起来等价、
* 实际在边界上会静默坏掉，而这样的坏不会让任何判据变红。
*
* 改坏会红：把 `nextActiveIndex(...)` 换回 `(this.suggestActive + 1) % len`。
*/
assert.match(COMPOSE, /nextActiveIndex\(/, '收件人键盘处理要调 nextActiveIndex');
assert.ok(
!/suggestActive\s*[-+]\s*1\)\s*%/.test(COMPOSE),
'不得自己就地写 %（负下标陷阱）'
);
assert.match(SUGGEST_UI, /\(\(current \+ delta\) % count \+ count\) % count/, '纯逻辑里才是那条公式');
});
test('2in1 快捷键｜↑↓ 换候选、Enter/Tab 选中、Esc 收起 —— 四个键都在', () => {
/*
* 对齐 WebUI `AddressInput.tsx:143-155`：
* ArrowDown → active+1 ；ArrowUp → active-1
* Enter | Tab → 选中当前项 ；Escape → 收起
*
* 改坏会红：删掉任一个 `else if` 分支 —— 用户按那个键就毫无反应。
*/
const at = COMPOSE.indexOf('onToKey');
assert.ok(at > 0, '要有 onToKey');
const body = braceBody(COMPOSE, 'private onToKey');
assert.match(body, /KEYCODE_DPAD_DOWN/, '↓ 要有');
assert.match(body, /KEYCODE_DPAD_UP/, '↑ 要有');
assert.match(body, /KEYCODE_ENTER/, 'Enter 要有');
assert.match(body, /KEYCODE_TAB/, 'Tab 要有');
assert.match(body, /KEYCODE_ESCAPE/, 'Esc 要有');
});
test('2in1 快捷键｜只响应 KeyType.Down（Down/Up 都处理会让一次按键走两步）', () => {
/*
* `KeyEvent` 对一次按键会派发 Down 与 Up 两个事件。两个都处理 ⇒
* 按一次 ↓ 下标移动 **2** 格，用户看到的是"跳着走"。
*
* 改坏会红：删掉 `if (e.type !== KeyType.Down) return;`。
*/
const body = braceBody(COMPOSE, 'private onToKey');
assert.match(body, /e\.type\s*!==\s*KeyType\.Down/, '要先挡掉非 Down 的按键事件');
});
test('2in1 快捷键｜候选列表内联渲染，不用 bindPopup/bindMenu', () => {
/*
* 这两者各有自己的焦点体系 —— 用户的按键会先被它们吃掉，
* "↑↓ 切换候选"就落不到 `onToKey` 上（菜单收不到、输入框也收不到）。
*
* 内联渲染（条件挂载）能让焦点一直留在输入框里 —— 这是键盘可达的前提。
*
* 改坏会红：把候选改成 `bindPopup(...)`。
*/
assert.ok(!/\.bindPopup\(/.test(COMPOSE), '不得用 bindPopup（会吃掉按键）');
assert.ok(!/\.bindMenu\(/.test(COMPOSE), '不得用 bindMenu（会吃掉按键）');
assert.match(COMPOSE, /if \(this\.suggestOpen && this\.suggestItems\.length > 0\)/, '候选要在布局里内联挂载');
});
test('2in1 快捷键｜候选标题读 title 时守住 omitempty 缺键', () => {
/*
* `SessionCandidate.Title` 带 `json:"title,omitempty"` ⇒ **整个键可能不存在**。
* ArkTS 的裸 cast（`JSON.parse(raw) as T`）在缺键时给 `undefined`，
* **不会**应用类里那个 `= ''` 默认值。
*
* 本仓已踩过同一个坑的另一个实例：`MailDetail.normalize()` 之前直接读
* `m.to.trim()`，服务端 omit 时就 `Cannot read property trim of undefined`
* ⇒ **整页白屏**。
*
* 改坏会红：把 `typeof raw === 'string' ? raw : ''` 换回 `cands[i].title`。
*/
assert.match(
COMPOSE,
/typeof raw === 'string' \? raw : ''/,
'读 title 前必须守一道（omitempty 缺键时是 undefined，不是空串）'
);
/* 而且模型里的字段名要跟服务端一致（服务端给的是 alias/title/source） */
const M = code(join(ETS, 'model/Models.ets'));
const cls = M.slice(M.indexOf('export class AddressSuggestion'));
assert.match(cls, /alias: string/, 'AddressSuggestion 要有 alias（服务端字段名）');
assert.ok(!/value: string/.test(cls.slice(0, 600)), '不得保留服务端从不返回的 value 字段');
});
/* ────────────────────────────────────────────────────────────────
* ④ 文档化：为什么用 keyboardShortcut 而不是 onKeyEvent
* ──────────────────────────────────────────────────────────────── */
test('2in1 快捷键｜选 keyboardShortcut 的理由写在源码里（否则后人会"顺手改成 onKeyEvent"）', () => {
/*
* 这条判据钉的不是代码，是**理由**。
*
* `onKeyEvent` 看着更"底层可控"，但官方文档写明：它要求**组件获焦**才触发
* （「按键事件是指组件与键盘、遥控器等按键设备交互时触发的事件，
* 适用于所有可获焦组件」）。而邮件列表里焦点落在哪是不确定的（点一下就换），
* 用 onKeyEvent 做全局快捷键会时灵时不灵。
*
* 而 `keyboardShortcut` 是「无论组件是否获焦 —— 只要窗口获焦，快捷键就会响应」。
*
* 改坏会红：把这段理由删了（后人看不到就会"顺手改成 onKeyEvent"）。
*/
assert.match(mainProse, /keyboardShortcut/, '注释里要写明用的是 keyboardShortcut');
assert.match(mainProse, /未获焦|获焦窗口/, '要写明"不依赖焦点"这条理由');
assert.match(PROSE_INTENT, /两半|当初|坑/, 'ComposeIntent 要留下"为什么需要中间层"的由来');
});

59
client/electron/test/harmony-nav.test.mjs
View File

@ -656,26 +656,53 @@ test('★ 顶部页签条与底部导航条同一族（都是悬浮玻璃）—
'页签条不许铺实体面（Theme.surface）—— 那是壁纸模式下唯一一块实心白，"割裂"就是这么来的');
assert.match(body, /\.backgroundBlurStyle\(this\.bgActive \? Theme\.navMaterial : BlurStyle\.NONE\)/,
'页签条要吃系统材质（与底部导航条同档），否则它和玻璃卡片拼在一起不是一套东西');
assert.match(body, /\.borderRadius\(TAB_BAR_RADIUS\)/,
'页签条要用 TAB_BAR_RADIUS（= NAV_BAR_RADIUS）—— 自己拍一个数会让上下两条不齐');
/*
* ★★ 2026-09-20：留白必须**算进宽度**，不能只写 `width('100%')` + `margin`。
* ══════════════════════════════════════════════════════════════════════
* ★★ 2026-09-21 **改判**：页签条不再自己成条，而是与窗格**齐平**
* ══════════════════════════════════════════════════════════════════════
*
* ArkUI 的 `width('100%')` 是按父容器算的，再叠 `margin` 会**向右溢出**
* 而不是把条挤窄 —— 实测（模拟器 3184px、密度 2.875）：页签条占 x=231..1151，
* 与面板**同宽**，`TAB_BAR_SIDE` 完全没生效；看起来仍是"通栏 + 圆角"，
* 与底部悬浮条不齐。
* 用户当天连指三次，最后一句是裁定：
* 「你看看顶栏右边那个圆角，你不觉得奇怪吗？」
* 「你右边改成没圆角不就行了，还 better，你好好看看，**你又在内部套了一个胶囊**」
* 「鸿蒙布局还略有不同的，你直接改成右边没圆角就行了」
*
* 这条断言是**从这次实测反推出来的**：单看代码"有 margin"会以为留白生效了，
* 而只有形如 `calc(100% - N vp)` 的宽度才真的让出那一段。
* ── 我原来错在哪（用 CDP 读 WebUI 的实测几何才发现）──
*
* .comm-pane x=80 w=320 radius=14px overflow=hidden ← 窗格，**裁圆的是它**
* tabstrip x=80 w=320 radius=0px ← 页签条，自己无圆角
*
* 两者**横向完全齐平**。而我们原来是"自己缩进 16vp + 自己带满圆角"⇒
* 页签条成了一个**嵌在窗格里的胶囊**，上下两条弧各画一遍，中间留出一弯月牙。
* 判据当时钉的 `TAB_BAR_RADIUS` / `TAB_BAR_SIDE` / `TAB_BAR_TOP`
* **正是那个被否掉的形状**——它记录的是旧实现，不是不变式。
*
* ── 设备实测（模拟器窄屏 1008px，`uitest dumpLayout`）──
*
* 页签条 Row bounds=[28,140][980,267]
* 所在窗格 bounds=[28,140][980,1957]
* ⇒ 左右边缘**逐像素相同**（28 / 980），与 WebUI 一致。
*
* ── 现在钉的三条（换成不变式，而不是"等于某个常量"）──
*
* ① 与窗格齐平：`width('100%')`，**不许**再有左右内缩
* （`margin`/`calc(100% - N)` 那两种写法都不行 —— 那会把胶囊加回来）；
* ② **右上角无圆角**（用户明确要求）：只给左上角，与窗格左上角那道弧**重合**成一道；
* ③ 依旧要有玻璃（与底部导航条同档），不许退回实体面。
*
* ★ `TAB_BAR_RADIUS` / `TAB_BAR_SIDE` / `TAB_BAR_TOP` 已随之**删除**
* （`model/NavItems.ts`）—— 留着它们就是**孤儿常量**：
* 下一个人会照着名字把胶囊拼回来。`TAB_BAR_HEIGHT` 保留（仍在用：
* 它决定条高，而条高是真实几何）。
*/
assert.ok(!/\.width\('100%'\)[\s\S]{0,200}?\.margin\(\{[^}]*left: TAB_BAR_SIDE/.test(body),
"页签条不能写 `width('100%')` + `margin` —— ArkUI 里那是向右溢出、留白不生效。\n" +
' 要用 `width(`calc(100% - ${TAB_BAR_SIDE * 2}vp)`)` 把留白算进宽度（设备实测的结论）');
assert.match(body, /\.width\(`calc\(100% - \$\{TAB_BAR_SIDE \* 2\}vp\)`\)/,
'页签条宽度要 `calc(100% - 2×TAB_BAR_SIDE)` —— 悬浮条的左右留白必须真的让出来');
assert.match(body, /\.margin\(\{[^}]*top: TAB_BAR_TOP/,
'页签条要留顶部间距（TAB_BAR_TOP）—— "浮着"而不是"贴着"内容区顶');
assert.match(body, /\.width\('100%'\)/,
'页签条要与窗格齐平（`width(\'100%\')`）—— WebUI 实测 .comm-pane 与 tabstrip 横向逐像素相同');
assert.ok(!/TAB_BAR_SIDE/.test(body),
'页签条不得再有左右内缩（TAB_BAR_SIDE 那个胶囊形状已被用户否掉）');
assert.match(body, /\.borderRadius\(\{\s*topLeft:\s*Theme\.glassRadius,\s*topRight:\s*0\s*\}\)/,
'页签条只许有**左上**圆角（右上 0）—— 用户：「你直接改成右边没圆角就行了」；' +
'右上那道弧会与窗格右上角的弧叠成两道');
assert.ok(!/\.borderRadius\(TAB_BAR_RADIUS\)/.test(body),
'页签条不得用 TAB_BAR_RADIUS（那是"胶囊"形状，已被否）');
/*
* 自检：把页签条改回实心面，上面第一条必须判红。

66
client/electron/test/harmony-widescreen.test.mjs
View File

@ -284,8 +284,36 @@ test('⑤ 宽屏 app-shell 几何：padding/gap/radius 与 WebUI 同值（一比
assert.match(theme, /static readonly paneGap: number = 10/, 'paneGap = 10（与 WebUI --pane-gap 同值）');
// Row 用 space=paneGap（gap）
assert.match(code_, /Row\(\{ space: Theme\.paneGap \}\)/, '宽屏 Row 用 space=paneGap（与 WebUI gap 同值）');
// 内容面板圆角只在宽屏启用（窄屏贴合全屏）
assert.match(code_, /borderRadius\(this\.isWide \? Theme\.glassRadius : 0\)/, '内容面板圆角宽屏 14 / 窄屏 0');
/*
* ★★ 2026-09-21 反转：原断言是
* `borderRadius(this.isWide ? Theme.glassRadius : 0)` —— 「宽屏 14 / 窄屏 0」。
*
* 那是**误读 WebUI**：它的两条 shell 规则**都给圆角**，差别只在留白 ——
*
* .app-shell > * { border-radius: var(--radius-card); } ← 宽屏
* .narrow-shell > * { border-radius: var(--radius-card); } ← 窄屏
* .app-shell { padding: var(--pane-gap); }
* .narrow-shell { padding: var(--pane-gap) var(--pane-gap) 0; } ← 只差底边
*
* 我当初把"窄屏底边留白为 0"顺手推广成了"窄屏什么都不留（含圆角）"，
* 于是窄屏四个窗格全是直角 —— 用户看出来的原话：「你的邮件的圆角呢？日历的圆角呢？」
*
* 新不变式（这才是 WebUI 的真正契约）：
* · 面板**必须有**圆角（两端都有）；
* · 且**不得**用 `isWide ? … : 0` 这种把圆角绑到宽窄上的写法。
*/
assert.match(code_, /borderRadius\(Theme\.glassRadius\)/,
'内容面板两端都要圆角（WebUI 的 `.app-shell > *` 与 `.narrow-shell > *` 都给 `--radius-card`）');
assert.ok(!/borderRadius\(this\.isWide \? Theme\.glassRadius : 0\)/.test(code_),
'★ 圆角不得绑在宽窄上（`isWide ? glassRadius : 0`）—— ' +
'WebUI 的两条 shell 规则**都给圆角**，差的只是留白；' +
'写成窄屏 0 会让四个窗格变直角，正是用户 2026-09-21 报的那个问题。');
/*
* 留白才是两端有别的那一处：宽屏四边都是 paneGap，窄屏底边为 0
* （底栏自己带 margin，内容要从它下面穿过 —— 见 `navReserve` 那段）。
*/
assert.match(code_, /left: Theme\.paneGap,[\s\S]{0,80}?right: Theme\.paneGap,/,
'左右留白两端都要（WebUI 两条 shell 的 padding 左右都是 --pane-gap）');
/*
* ★★ 2026-09-20 改：原来这条断言的是
* assert.match(code_, /clip\(this\.isWide\)/, '面板内容要被圆角裁剪（clip 宽屏才开）');
@ -307,15 +335,41 @@ test('⑤ 宽屏 app-shell 几何：padding/gap/radius 与 WebUI 同值（一比
* 原来那条测的是"某句实现写着没写着"（且那实现是错的），
* 现在测的是"与 WebUI 同一条几何纪律"：圆角在、`overflow:hidden` 不在。
*/
assert.match(code_, /borderRadius\(this\.isWide \? Theme\.glassRadius : 0\)/,
'宽屏圆角开（14）/ 窄屏 0 —— 与 WebUI `.app-shell > *` 同值');
/*
* 圆角：两端都开。
*
* ★★ 2026-09-21 反转（原句是 `borderRadius(this.isWide ? Theme.glassRadius : 0)`）。
* 见上面那条断言的说明：WebUI 的两条 shell 规则**都给圆角**，
* 差的只是留白。写成"窄屏 0"是我把"底边留白为 0"错推广成了"什么都不留"。
* 用户原话：「你的邮件的圆角呢？日历的圆角呢？」。
*/
assert.match(code_, /borderRadius\(Theme\.glassRadius\)/,
'内容面板两端都要圆角 —— 与 WebUI `.app-shell > *` / `.narrow-shell > *` 同值（都是 `--radius-card`）');
assert.ok(!/borderRadius\(this\.isWide \? Theme\.glassRadius : 0\)/.test(code_),
'★ 圆角不得绑宽窄（`isWide ? glassRadius : 0`）—— 窄屏会变直角');
assert.match(code_, /attributeModifier\(GlassCardModifier\.of\(this\.bgActive\)\)/,
'宽屏内容列的面来自设计令牌（不是就地写死一个实心 surface）');
assert.ok(!/\.clip\(this\.isWide\)/.test(code_),
'宽屏内容列**不能**写 `.clip(this.isWide)` —— 会把 `Navigation` 里 List 的滚动整条裁掉'
+ '（WebUI `index.css:968` 在同一个规则块里写明了这条，2026-09-14 用户实测"无法上下滑动"）');
// 容器 padding 宽屏 paneGap / 窄屏 0（壁纸从缝隙露出）
assert.match(code_, /left: this\.isWide \? Theme\.paneGap : 0/, '宽屏容器左右 padding paneGap（窄屏 0 贴合全屏）');
/*
* 容器左右留白 —— 两端都要 `paneGap`。
*
* ★★ 2026-09-21 反转：原句是 `left: this.isWide ? Theme.paneGap : 0`
* （「窄屏 0 贴合全屏」）。那是我把 WebUI 的
* .narrow-shell { padding: var(--pane-gap) var(--pane-gap) 0; }
* 读成了"窄屏不留白" —— 它**左右上三边都留 gap**，只有**底边**为 0
* （底栏自带 margin，内容要从它下面穿过）。
* 后果：窄屏面板贴死屏幕两侧，既没圆角的余地也没投影的余地，
* 看起来是一块被屏幕裁掉的白板 —— 用户：「邮箱页面丑死了，跟 WebUI 没法比」。
*/
assert.match(code_, /left: Theme\.paneGap,/,
'容器左右留白两端都要（WebUI `.narrow-shell` 的 padding 左右也是 `--pane-gap`）');
assert.ok(!/left: this\.isWide \? Theme\.paneGap : 0/.test(code_),
'★ 左右留白不得绑宽窄（窄屏会贴死屏幕两侧）');
/* 真正两端有别的只有**底边**：宽屏补 paneGap，窄屏 0（底栏自己带 margin） */
assert.match(code_, /bottom: this\.isWide \? Theme\.paneGap : 0/,
'底边留白才是两端有别的那一处：宽屏 paneGap / 窄屏 0（底栏自带 margin）');
});
test('⑦ 导航项徽标：取值/色调与 WebUI Sidebar 同口径（纯逻辑，不需要设备）', async () => {
/*

5
client/electron/test/run-all.mjs
View File

@ -130,6 +130,11 @@ const SUITE = [
// ArkTS **编译期**硬规则（纯文本可判、不需要设备）。这一条是构建撞出来的：
// 我把常量表插在了既有 import 之前 ⇒ arkts-no-misplaced-imports，而当时没有任何判据会跑它。
['test/harmony-arkts.test.mjs', [], 8],
/*
* 2in1 键盘可达（用户 2026-09-21「快捷键打开发信页面 / 上下键切换发信目标 /
* 回车展开输入框」）。见该文件头部说明：为什么单开一个文件、为什么不端到端验。
*/
['test/harmony-2in1.test.mjs', [], 12],
['test/harmony-contacts.test.mjs', [], 5],
// ★★ 下面三条是**补接线**，不是新写的判据（2026-09-17）。
//

35
client/harmony/entry/src/main/ets/api/MailApi.ets
View File

@ -6,7 +6,7 @@
*/
import { ApiClient } from './ApiClient';
import { MailSummary, Session, Contact, MailDetail, ThreadResponse, ThreadNode, AttachmentInfo, SendMailRequest, SendMailResult, SentResponse, PermissionRequest, PendingResponse, DecideResponse, ForwardMailRequest} from '../model/Models';
import { MailSummary, Session, Contact, MailDetail, ThreadResponse, ThreadNode, AttachmentInfo, SendMailRequest, SendMailResult, SentResponse, PermissionRequest, PendingResponse, DecideResponse, ForwardMailRequest, AddressSuggestion} from '../model/Models';
/** 收件箱响应 */
export class InboxResponse {
@ -85,6 +85,17 @@ export class AttachmentListResponse {
/** 地址补全响应 */
export class AddressSuggestionResponse {
suggestions: string[] = [];
/**
* 与 `suggestions` **按下标一一对应**的补充信息
* （会话别名会有 `title`；`name`/`path` 段可能为空数组）。
*
* ★ 服务端按两层返回：`suggestions` 是纯字符串、`candidates` 是对象。
* 过滤时必须**同时**按下标保留两者，否则标题会错位到别的别名上
* （WebUI `AddressInput.tsx:60-65` 那段注释专门记了这条）。
*/
candidates: AddressSuggestion[] = [];
/** 当前问的是哪一层：`name` | `path` | `session` */
kind: string = '';
}
/** 改权限请求体 */
@ -202,6 +213,28 @@ export class MailApi {
return this.client.get<ContactListResponse>('/contacts');
}
/**
* 三维地址补全（`GET /contacts/suggest?name=&path=`）。
*
* 三段式（与 WebUI `AddressInput` 同口径，服务端 `contacts.go:143` 同一份实现）：
* · 还没写 `@` → 问 name（Agent 名 + 人类用户名）
* · 写了 `@` 没写 `.` → 问该 Agent 的工作区路径
* · 写了 `.` → 问该工作区下的会话别名（含 `new`）
*
* ★ 为什么要传空串而不是省略参数：服务端的判据是"参数有没有给"，
* 不是"值是否为空"。省略会让它退回到上一层。
*/
async suggestAddress(name: string, path: string): Promise<AddressSuggestionResponse> {
let q: string = '';
if (name.length > 0) {
q = '?name=' + encodeURIComponent(name);
if (path.length > 0) {
q = q + '&path=' + encodeURIComponent(path);
}
}
return this.client.get<AddressSuggestionResponse>('/contacts/suggest', q);
}
/**
* 一条会话下的全部邮件（`GET /sessions/{id}/mails`）。
*

82
client/harmony/entry/src/main/ets/common/ComposeIntent.ets Normal file
View File

@ -0,0 +1,82 @@
/**
* 「打开写信」的**跨组件一次性意图**。
*
* 用户 2026-09-21：「接下来做一下 2in1 上的快捷键，比如快捷键打开发信页面」。
*
* ## 为什么需要这个中间层
*
* 快捷键必须绑在**根**（`MainPage` 的根 `Stack`）—— 官方 `keyboardShortcut`
* 文档说「即使组件未获焦或是在所在页面未展示，只要已经挂载到**获焦窗口**的
* 组件树上就会响应」，而"窗口级生效"只有绑在窗口组件树的根上才成立。
*
* 但 `openCompose()` 住在 `CommPage` 上（写信要 `CommPage` 自己的 `navPathStack`，
* 宽屏 Split 时才能在右栏开 —— 见 `MainPage.openComposeWith()` 的注释）。
* 于是 `MainPage` 的快捷键够不着那个方法。
*
* ## 做法：照抄本仓已经验证过的"两半"形状
*
* `api/PushService.ets` 处理"点通知要跳转"时踩过同一个坑，解法写在它的注释里：
* · **第一半**：一个静态格子（`pending`）—— 冷启/尚未挂载时，请求先存着；
* · **第二半**：一个回调（`listener`）—— 已经挂载时，请求当场送达。
*
* 缺任何一半都会漏一种情形：
* · 只有格子 ⇒ 用户此刻就在通信页、页面早挂载完了，`aboutToAppear` 不重跑
* ⇒ **按了快捷键什么都没发生**；
* · 只有回调 ⇒ 用户此刻在日历页，`CommPage` 因 `if (currentIndex === 0)`
* 尚未挂载 ⇒ 没有任何监听者 ⇒ **同样什么都没发生**。
*
* ## 谁负责切到通信页
*
* `request()` **不管** UI 导航（那是 `MainPage` 的事：它得先把 `currentIndex`
* 拨到 0，`CommPage` 才会挂载）。这里只管"把意图存住/交出去"。
* 分开的好处：`MainPage` 里那两行是**唯一**需要读当前 tab 的地方，
* 而本类保持无 UI 依赖 —— 可被条件挂载的两侧都安全调用。
*/
export class ComposeIntent {
/**
* 还没人接手的一次请求。
*
* 用静态格子而不是 `AppStorage`：这与 `PushService.pendingRoute` 同一理由 ——
* 发起方（根组件）和接手方（条件挂载的 `CommPage`）之间只隔一次挂载，
* 不需要一个全局可观察的状态；而用了 `@StorageLink` 反而要处理
* "读到之后怎么清"（不清会重放，清了会触发另一轮刷新）。
*/
static pending: boolean = false;
/** 已经在监听的那一处（同一时刻只可能有一处：`CommPage` 是唯一的写信持有者） */
private static listener: (() => void) | undefined = undefined;
/** `CommPage` 挂载时登记 */
static setListener(fn: () => void): void {
ComposeIntent.listener = fn;
}
/** `CommPage` 卸载时摘掉（否则会唤醒一个已销毁的组件） */
static clearListener(): void {
ComposeIntent.listener = undefined;
}
/**
* 提"我要写信"。
*
* **有人监听就当场交出去；没人监听就存着等挂载后取走** —— 两半都留着，
* 因为两种时刻各走一条（用户此刻在通信页 / 在别的页）。
*/
static request(): void {
const fn: (() => void) | undefined = ComposeIntent.listener;
if (fn !== undefined) {
fn();
return;
}
ComposeIntent.pending = true;
}
/** 取走待处理的请求（取完即清，避免下次挂载时重放） */
static consume(): boolean {
if (!ComposeIntent.pending) {
return false;
}
ComposeIntent.pending = false;
return true;
}
}

106
client/harmony/entry/src/main/ets/common/Theme.ets
View File

@ -195,29 +195,58 @@ export class Theme {
static readonly cardMaterial: BlurStyle = BlurStyle.BACKGROUND_THIN;
/*
* ── 玻璃的**参数化**配方（比材质档更接近 WebUI）──
* ── 关于「参数化玻璃」（`backgroundEffect`）：**本工程不用** ──
*
* `BlurStyle` 是**固定档**（系统给的那几组），而 WebUI 的玻璃是**显式参数**：
* 2026-09-21 实测记录（我被自己的实验推翻，留证以免后人再走一遍）。
*
* .narrow-nav backdrop-filter: blur(18px) saturate(1.5) ← 浮条
* --bg-blur-panel: 10px ← 面板
* 这里原先有两个令牌 `glassCardRadius = 18` / `glassCardSaturation = 1.5`，
* 注释自己写着「与 WebUI `.narrow-nav` 逐字同源」—— 也就是**底部导航条**
* 那一档（`index.css:1204`：`backdrop-filter: blur(18px) saturate(1.5)`），
* 名字却叫 `glass**Card**…`。名与实不符立刻兑现了代价：
* 我照名字把它挂到了**每张卡片**上，而 WebUI 的卡片根本没有 `backdrop-filter`
* （`.glass-card` 只有白 + alpha）⇒ 多层模糊叠加成灰雾 + 滚动掉帧。
*
* 关键差别是 **saturate（饱和度增强）**：它让透过玻璃的颜色更鲜艳，
* 正是"玻璃感"的主要来源。`BlurStyle` 没有这个旋钮，
* 所以纯用材质档会偏灰 —— 用户说"不够炫酷"就是这个观感。
* 上一轮"卡片去模糊"之后，这两个令牌**失去全部消费者** ——
* 是 `cross-client-theme` 的**孤儿令牌判据**把它们报出来的
* （「这些 Theme 令牌在页面/组件里一次都没被引用」），
* 而不是烂在那里没人知道。
*
* ArkUI 的参数化 API 是 `backgroundEffect({ radius, saturation, brightness })`，
* 字段与 CSS 的 `backdrop-filter` 一一对应，于是可以**照抄 WebUI 的数**。
* 取值规则（不是拍的）：
* · `CARD_RADIUS = 18` / `CARD_SATURATION = 1.5` —— 与 WebUI `.narrow-nav`
* 逐字同源（那是 WebUI 里最"玻璃"的一档）。卡片面积小，用最有质感的档；
* · 面板面积大、透太多会伤正文可读性 ⇒ 用 `--bg-blur-panel: 10px`，
* 饱和度取 1.3（比 1.5 收一点 —— 大面积高饱和会让整页发艳）。
* ── 我接着做了一次实验，然后被实测否掉 ──
*
* ★ 为什么不直接抄 1.5 给面板：WebUI 那边这两个值本来就是**分开的**
* （10px 面板 / 18px 浮条），抄就得抄全套，不能只挑一个数。
* 我推断「真归属是导航条」，于是把底栏从
* `backgroundBlurStyle(Theme.navMaterial)` 改成
* `backgroundEffect({radius:18, saturation:1.5})`，理由是
* 「固定材质档没有 `saturate` 旋钮、观感偏灰」。
*
* 实测（模拟器窄屏 1008×2232，取底栏中心列 x=504 的像素）：
*
* y backgroundEffect backgroundBlurStyle
* 1960 rgb(191,199,209) rgb(234,235,239) ← 差 -36 亮度
* 2000 rgb(198,204,212) rgb(234,235,239) ← 差 -31
* 2060 rgb(206,211,219) rgb(234,235,239) ← 差 -24
*
* ⇒ `backgroundEffect` **只给模糊、不给底色**，壁纸原样透上来，
* 整条底栏暗了 24~36 个亮度级 —— 比原来的"偏灰"糟得多。
*
* ★ 为什么：WebUI 的 `.narrow-nav` 是**两条声明**组合出来的 ——
* background-color: rgb(var(--nav-bg));
* backdrop-filter: blur(18px) saturate(1.5);
* 我只搬了后者、丢了前者。而 `backgroundBlurStyle` 的**系统材质本身**
* 就同时含「色调 + 模糊 + 深浅两套」，正好把这两条一起给了。
*
* ★ 更要紧的一层：WebUI 那个 `--nav-bg` 是**手写 alpha**，跟不了深色主题
* （§7.12 那一行的原话：「手写 alpha 跟不了深色」）。⇒ 在这里系统材质
* 不是"退而求其次"，而是**唯一能同时满足深浅两套**的方案。
* §7.12 当初把这条判成"有意差异"是对的，我的"改进"才是退步。
*
* ⇒ 结论：`navMaterial`（`BlurStyle.COMPONENT_THICK`）保持不变；
* 两个令牌**删除**（不删就是孤儿，孤儿判据会一直红着）。
*
* ★ 留这段注释而不是直接删干净的原因：**下一个人会再想一遍同样的事**
* （WebUI 那行 `saturate(1.5)` 就摆在那里，很显眼）。
* 把"试过了、实测数字在此、结论是不要"写在这里，
* 比让他重跑一遍模拟器便宜。
*/
static readonly glassCardRadius: number = 18;
/*
* ── 卡片的"玻璃"：**白色 + alpha，不做模糊** ──
*
@ -256,9 +285,30 @@ export class Theme {
* 「基材恒为白，主题之间只差 alpha」）。深色下靠 `brightness` 与
* 文字令牌保证对比度，而不是把底也调黑。
*/
/*
* ── 卡片底：白色 + alpha（**与 WebUI `.glass-card` 逐字同源**）──
*
* index.css:1629 .glass-card → rgb(255 255 255 / 0.92)
* index.css html[data-bg='on'] … → rgb(255 255 255 / 0.78)
* ⇒ glassCard #EBFFFFFF（0.92 × 255 ≈ 235 = 0xEB）
* ⇒ glassCardWall #C7FFFFFF（0.78 × 255 ≈ 199 = 0xC7）
*
* ★ 为什么必须是**手写色**而不是 `$r('sys.*')`：
* 系统材质（`bgMaterial*` / `compBackground*`）是**不透明**的整块色板，
* 没有"白 92% 叠在壁纸上"这一档。而 WebUI 的玻璃观感**正是**这个 alpha
* —— 它不是模糊（`.glass-card` 全仓没有 `backdrop-filter`，只有
* `.glass-control` 与 `.narrow-nav` 有）。换成系统材质 ⇒ 壁纸被整块盖死，
* 那正是用户报的「玻璃不透明」。
*
* ★ 为什么用"白 + alpha"而不去调亮度模拟：
* 壁纸是**用户可换的图**，颜色不可预知；只有半透明白能同时适配浅壁纸
* 与深壁纸（深色档另有 `DARK_DIM_MIN` 兜底）。
*
* 已登记进 `cross-client-theme.test.mjs` 的 `SELF_OWNED_COLORS`
* （那条判据会红着提醒"理由不能只存在于写它那个人的记忆里"）。
*/
static readonly glassCard: string = '#EBFFFFFF';
static readonly glassCardWall: string = '#C7FFFFFF';
static readonly glassCardSaturation: number = 1.5;
/**
* 「悬浮玻璃板」的另外两半：**投影 + 发丝描边**。
*
@ -386,6 +436,26 @@ export class Theme {
* 'plain' 档徽标底色（联系人数）。★ 必须石板灰而非红：
* 三档被压成两档时 `'plain'` 会走 danger，看着像"有未读"
*
* ★★ 2026-09-21 补登记：`glassCard` / `glassCardWall`
*
* · glassCard #EBFFFFFF WebUI `.glass-card`（`index.css:1629`）
* `background-color: rgb(255 255 255 / 0.92)`
* （0.92 × 255 ≈ 235 = 0xEB）
* · glassCardWall #C7FFFFFF 上者的"有壁纸"档 —— WebUI
* `html[data-bg='on'] .glass-card` 的 `… / 0.78`
* （0.78 × 255 ≈ 199 = 0xC7）
*
* 为什么必须自己写而不是走 `$r('sys.*')`：系统材质
* （`bgMaterial*` / `compBackground*`）是**不透明**的整块色板，
* 没有"白 92% 叠在壁纸上"这一档。而 WebUI 的玻璃观感**正是**这个 alpha
* —— 它**不是**模糊（`.glass-card` 全仓没有 `backdrop-filter`；
* 只有 `.glass-control` 与 `.narrow-nav` 有）。换成系统材质 ⇒ 壁纸被
* 整块盖死，那正是用户报的「玻璃不透明」。
*
* 为什么是"白 + alpha"而不是调亮度模拟：壁纸是**用户可换的图**，
* 颜色不可预知；只有半透明白能同时适配浅壁纸与深壁纸
* （深色档另有 `DARK_DIM_MIN` 兜底）。
*
* SSE 连接指示器的四个状态色（逐档对齐 WebUI 的 Tailwind 类，
* `ConnectionIndicator.tsx:22-25`）：
* · sseConnected #22C55E bg-green-500 已连接

200
client/harmony/entry/src/main/ets/model/AddressSuggest.ts Normal file
View File

@ -0,0 +1,200 @@
/**
* 三维地址补全 —— **纯逻辑**（无 ArkUI / 无 @kit 导入，可被 node 直接跑）。
*
* 用户 2026-09-21：
* · 「接下来做一下 2in1 上的快捷键，比如快捷键打开发信页面」
* · 「上下键切换发信目标」
* · 「回车展开输入框等」
*
* 为什么单独成文件、且**不引任何 @kit**：本仓的 `cross-client-logic.test.mjs`
* 会把 `.ts` 模型文件用 `--experimental-strip-types` 直接跑起来，与 electron
* 的同名逻辑逐例比对。带 `@kit` 导入的 `.ets` 做不到这件事（见那条判据的注释）。
*
* ## 与 WebUI 的关系
*
* WebUI 的实现是 `components/AddressInput.tsx`，逻辑散在组件里（`parseParts`
* 是模块级函数，`apply` 是闭包）。这里把它**抽成纯函数**：
* · `parseParts` —— 逐字照搬（`AddressInput.tsx:247`）
* · `mergeCandidate` —— `apply`（`:129`）的等价物，但不碰 React state
* · `nextActiveIndex` —— `onKeyDown` 里两个 `setActive` 的等价物
* · `chooseEndpoints` —— 决定"问哪一层"（`AddressInput.tsx:50-58` 的判据）
*
* ★ 抽出来还有一个好处：**键盘行为可以单测**。"上下键循环"这种逻辑一旦
* 写成组件闭包，就只能靠手动点击验；写成纯函数就能钉住边界（回绕、
* 空列表、单元素）。
*/
/** 地址的三段（`name@path.session`）。 */
export class AddressParts {
name: string = '';
path: string = '';
session: string = '';
hasAt: boolean = false;
hasDot: boolean = false;
}
/**
* 把编辑中的一段拆成三段。
*
* 逐字对齐 WebUI `AddressInput.tsx:247-265`：
* · 没有 `@` ⇒ 整串都是 name
* · 有 `@` 没 `.` ⇒ `@` 之后是 path
* · 都有 ⇒ 以**最后一个** `.` 为界（`.` 之后是 session）
*
* ★ 最后那个"用 `lastIndexOf('.')` 而不是 `indexOf`"是有意的：工作区路径
* 里可能带点（例如 `home/program/agentmail` 不含，但 `a.b/c` 含）。
* 取最后一个点，才能让"会话别名"始终是最后一段。
*/
export function parseParts(s: string): AddressParts {
const p: AddressParts = new AddressParts();
const at: number = s.indexOf('@');
if (at < 0) {
p.name = s;
return p;
}
p.name = s.slice(0, at);
p.hasAt = true;
const rest: string = s.slice(at + 1);
const dot: number = rest.lastIndexOf('.');
if (dot < 0) {
p.path = rest;
return p;
}
p.path = rest.slice(0, dot);
p.session = rest.slice(dot + 1);
p.hasDot = true;
return p;
}
/**
* 把选中的候选**拼回**一段完整地址。
*
* 对齐 WebUI `AddressInput.tsx:129-141` 的 `apply`：
* · 选完 name → `{name}@` （后面还等着写 path）
* · 选完 path → `{name}@{path}.` （后面还等着写 session）
* · 选完 session → 完整三段
*
* ★ 为什么 name/path 后面要**补上分隔符**：这样用户接着打字就自然进入下一段，
* 而不必自己敲 `@` 或 `.`。WebUI 的注释写着「name/path 选完仍停留在补全态，
* 继续下一段」——补分隔符是那件事的前提。
*/
export function mergeCandidate(parts: AddressParts, kind: string, choice: string): string {
if (kind === 'name') {
return choice + '@';
}
if (kind === 'path') {
return parts.name + '@' + choice + '.';
}
return parts.name + '@' + parts.path + '.' + choice;
}
/**
* 上下键移动时的下一个下标（**循环**）。
*
* 对齐 WebUI `AddressInput.tsx:145-150`：
* setActive(i => (i + 1) % items.length)
* setActive(i => (i - 1 + items.length) % items.length)
*
* ★ 那个 `+ items.length` 不是多余：JS 的 `%` 对负数返回负数
* （`-1 % 5 === -1`），所以直接写 `(i-1) % n` 会得到负下标。
* 这类边界正是把它抽成纯函数后才测得出来的。
*
* 列表为空时返回 0（没有可选项，任何下标都无意义，但也不能返回负数）。
*/
export function nextActiveIndex(current: number, count: number, delta: number): number {
if (count <= 0) {
return 0;
}
return ((current + delta) % count + count) % count;
}
/**
* 候选菜单要不要向上翻转。
*
* 对齐 WebUI `AddressInput.tsx:104-112`：比较输入框上方与下方各有多少空间，
* 下方不够（且上方更多）时向上翻。
*
* ★ 为什么抽出来：这个判据决定了菜单会不会**盖住输入框**，
* 而它只看两个数，很适合用纯函数钉住（"下方够就不翻"、"下方不够就翻"、
* "两边都够就用下方"）。
*
* @param spaceAbove 输入框上方可用高度（vp）
* @param spaceBelow 输入框下方可用高度（vp）
* @param need 菜单希望占的高度（vp）
*/
export function shouldFlipUp(spaceAbove: number, spaceBelow: number, need: number): boolean {
const want: number = Math.min(need, spaceAbove);
return spaceBelow < want && spaceAbove > spaceBelow;
}
/**
* 按当前输入决定"问哪一层"并返回查询参数。
*
* 对齐 WebUI `AddressInput.tsx:50-56`：
* 有 `.` → 问 session（传 name + path）
* 有 `@` → 问 path（只传 name）
* 都没有 → 问 name（不传参数）
*
* 返回值用**具名类**而不是对象字面量：ArkTS 的 `arkts-no-untyped-obj-literals`
* 不允许裸字面量（这条在 `.ts` 里同样被 linter 管）。
*/
export class SuggestQuery {
name: string = '';
path: string = '';
/** 期望的层级，仅用于内部判断（服务端也会回一个 `kind`） */
kind: string = 'name';
}
export function queryFor(parts: AddressParts): SuggestQuery {
const q: SuggestQuery = new SuggestQuery();
if (parts.hasDot) {
q.name = parts.name;
q.path = parts.path;
q.kind = 'session';
} else if (parts.hasAt) {
q.name = parts.name;
q.kind = 'path';
} else {
q.kind = 'name';
}
return q;
}
/**
* 过滤候选 —— **必须保持 suggestions 与 candidates 的同序**。
*
* 对齐 WebUI `AddressInput.tsx:60-70`。那段注释原文：
* 「过滤时保持 suggestions 与 candidates 同序：candidates 是按下标对应的，
* 分别过滤两个数组会让标题错位到别的别名上。」
*
* 还有一条容易漏的：**标题也参与匹配**（`hay` 里拼了 `title`）——
* 「想找「缓存选型」那条会话时，人记得的是标题而不是随机短名」。
*
* @returns 保留下来的下标（升序）
*/
export function filterIndexes(suggestions: string[], titles: string[], fragment: string): number[] {
const keep: number[] = [];
const lower: string = fragment.toLowerCase();
for (let i = 0; i < suggestions.length; i++) {
const title: string = i < titles.length ? titles[i] : '';
const hay: string = title.length > 0
? (suggestions[i] + ' ' + title).toLowerCase()
: suggestions[i].toLowerCase();
if (hay.indexOf(lower) >= 0) {
keep.push(i);
}
}
return keep;
}
/** 把"保留下来的下标"作用到任意两个同长数组上（两处调用保持一致） */
export function pickBy<T>(arr: T[], indexes: number[]): T[] {
const out: T[] = [];
for (let i = 0; i < indexes.length; i++) {
const idx: number = indexes[i];
if (idx >= 0 && idx < arr.length) {
out.push(arr[idx]);
}
}
return out;
}

21
client/harmony/entry/src/main/ets/model/Models.ets
View File

@ -371,10 +371,25 @@ export class UserKey {
key_token: string = '';
}
/** 地址补全候选 */
/**
* 地址补全候选（服务端 `repo.SessionCandidate`，**只有 `session` 层才有**）。
*
* ★ 原声明写的是 `value`/`kind` —— 服务端从来没返回过这两个字段
* （`contacts.go:206-210` 只给 `alias`/`title`/`source`）。
* 本仓纪律：「声明了服务端从不返回的字段 ⇒ 删掉声明」。已按实际形状改正。
*
* ★ `title` 带 `omitempty`（`platform_sessions.go:95`）⇒ **键可能不存在**。
* ArkTS 的裸 cast（`JSON.parse(raw) as T`）在缺键时给 `undefined`，
* **不会**应用这里的 `= ''` 默认值。读它必须守，否则
* `Cannot read property of undefined`（本仓踩过同一个坑，见 `MailDetail.normalize`）。
*/
export class AddressSuggestion {
value: string = '';
kind: string = '';
/** 填进 session 位的值 */
alias: string = '';
/** 给人看的标题；**服务端可能整个键都不返回**（omitempty） */
title: string = '';
/** 从哪来：mail（本侧线索，可直接送达）/ platform（平台侧镜像）/ new */
source: string = '';
}
/** 发信请求体 */

20
client/harmony/entry/src/main/ets/model/NavItems.ts
View File

@ -333,8 +333,24 @@ export function navBadgeText(n: number): string {
* 直接引 `HEADER_HEIGHT` 报 "used before its declaration"。）
*/
export const TAB_BAR_HEIGHT: number = 44;
export const TAB_BAR_RADIUS: number = TAB_BAR_HEIGHT / 2;
export const TAB_BAR_SIDE: number = NAV_BAR_SIDE;
/*
* ★★ 2026-09-21 **删除 `TAB_BAR_RADIUS` / `TAB_BAR_SIDE`**。
*
* 它们服务的是"页签条自己成一条悬浮胶囊"那套形状，而那套形状被用户否掉了：
* 「你又在内部套了一个胶囊」「你直接改成右边没圆角就行了」。
* 现在的页签条与窗格**齐平**、只有左上角一道弧（详见 `MainPage.CommTabBar()`
* 与 `harmony-nav.test.mjs` 那条判据里记的 WebUI 实测几何）。
*
* ★ 为什么必须**删**而不是留着不用：留着它们就是**孤儿常量**。
* 下一个人看到 `TAB_BAR_RADIUS` 这个名字，很自然会把胶囊拼回来 ——
* 而我当初就是从"这两个常量存在"推出"页签条该是个胶囊"的。
* 名字与常量在，错误的设计就一直在邀请别人复现它。
*/
/*
* `TAB_BAR_TOP` 保留：**仍在使用**，但换了主人 ——
* `HEADER_TOP`（统一顶栏的顶部留白）就是它（见本文件末尾）。
* 页签条现在与窗格齐平，不再需要顶部浮起留白。
*/
/** 顶部留白（vp）：离内容区顶部一点点，做成"浮着"而不是"贴着" */
export const TAB_BAR_TOP: number = 8;

166
client/harmony/entry/src/main/ets/pages/ComposePage.ets
View File

@ -5,7 +5,7 @@
*/
import { ApiClient, ApiError } from '../api/ApiClient';
import { Theme } from '../common/Theme';
import { MailApi } from '../api/MailApi';
import { MailApi, AddressSuggestionResponse } from '../api/MailApi';
import { AccountManager, AccountInfo } from '../api/AccountManager';
import { SendMailRequest } from '../model/Models';
import { ComposeParams } from '../model/RouteParams';
@ -15,6 +15,8 @@ import { AmIcon } from '../common/Icons';
import { Insets, KEY_WINDOW_INSETS, topInset } from '../model/WindowInsets';
import { PressEffectModifier } from '../common/Surface';
import { Motion } from '../common/Motion';
import { KeyCode } from '@kit.InputKit';
import { parseParts, mergeCandidate, nextActiveIndex, queryFor, filterIndexes, AddressParts, SuggestQuery } from '../model/AddressSuggest';
/**
* 写邮件窗格。
@ -86,6 +88,134 @@ export struct ComposeView {
@State accountList: AccountInfo[] = [];
@State selectedAccountId: string = '';
@State showAccountPicker: boolean = false;
/*
* ── 收件人候选补全（用户 2026-09-21：「上下键切换发信目标」「回车展开输入框」）──
*
* 与 WebUI `AddressInput.tsx` 同口径，规则本身在 `model/AddressSuggest.ts`
* （纯逻辑，已被 `cross-client-logic.test.mjs` 与 electron 逐例比对）。
* 这里只放**界面状态**。
*/
@State suggestItems: string[] = [];
@State suggestTitles: string[] = [];
@State suggestActive: number = 0;
@State suggestOpen: boolean = false;
/** 输入防抖（WebUI 是 120ms；打字每字符都打接口会打断输入） */
private suggestTimer: number = -1;
/**
* 收件人输入变化 —— 防抖后拉候选。
*
* 与 WebUI `AddressInput.tsx:49-85` 同一流程：拆段 → 决定问哪一层 →
* 拉 → 按当前片段过滤（**下标同序**）。
*
* ★ 防抖 120ms 与 WebUI 同值：每个字符都打接口会打断输入（网络往返期间
* UI 线程虽不阻塞，但候选会跳）。
*/
private onToChanged(v: string): void {
this.to = v;
if (this.suggestTimer >= 0) {
clearTimeout(this.suggestTimer);
}
this.suggestTimer = setTimeout(() => {
this.fetchSuggestions();
}, 120);
}
private async fetchSuggestions(): Promise<void> {
const ctx = this.getUIContext().getHostContext();
if (ctx === undefined) {
return;
}
const api: MailApi | null = this.createSelectedMailApi(ctx);
if (api === null) {
return;
}
const parts: AddressParts = parseParts(this.to);
const q: SuggestQuery = queryFor(parts);
try {
const res: AddressSuggestionResponse = await api.suggestAddress(q.name, q.path);
const all: string[] = res.suggestions ?? [];
const cands = res.candidates ?? [];
/*
* 取标题 —— `title` 带 `omitempty`，缺键时裸 cast 给的是 `undefined`
* （**不是** 类里那个 `= ''`）。所以用 `typeof` 守一道再取。
*/
const titles: string[] = [];
for (let i = 0; i < cands.length; i++) {
const c = cands[i];
const raw: string | undefined = c === undefined ? undefined : c.title;
titles.push(typeof raw === 'string' ? raw : '');
}
/* 片段：没写 @ 时用 name、写了 @ 用 path、写了 . 用 session（与 queryFor 同层） */
const frag: string = parts.hasDot ? parts.session : (parts.hasAt ? parts.path : parts.name);
const keep: number[] = filterIndexes(all, titles, frag);
const items: string[] = [];
const keepTitles: string[] = [];
for (let i = 0; i < keep.length; i++) {
items.push(all[keep[i]]);
keepTitles.push(titles[keep[i]] ?? '');
}
this.suggestItems = items;
this.suggestTitles = keepTitles;
this.suggestActive = 0;
this.suggestOpen = items.length > 0;
} catch {
/*
* 拉不到候选**不是错误**：静默收起，用户照常手打地址。
* ★ 这里刻意用**无绑定** catch：写 `catch (e)` 会让 `e` 是 `any`，
* 撞 `arkts-no-any-unknown`（工程里别处也是这个写法）。
*/
this.suggestItems = [];
this.suggestTitles = [];
this.suggestOpen = false;
}
}
/** 选中一个候选 —— 拼回地址；name/path 段选完**仍停在补全态**（继续下一段） */
private applySuggestion(choice: string): void {
const parts: AddressParts = parseParts(this.to);
const kind: string = parts.hasDot ? 'session' : (parts.hasAt ? 'path' : 'name');
this.to = mergeCandidate(parts, kind, choice);
if (kind === 'session') {
this.suggestOpen = false;
this.suggestItems = [];
} else {
/* 还有下一段要选 ⇒ 立刻再拉一次（WebUI 同行为） */
this.fetchSuggestions();
}
}
/**
* 收件人输入框的键盘处理 —— **这就是用户要的那几条**：
* · ↑ / ↓ 切换候选（`nextActiveIndex` 负责循环）
* · Enter / Tab 选中当前候选
* · Esc 收起候选
*
* ★ 用 `onKeyEvent` 而不是 `keyboardShortcut`：后者是**全局组合键**
* （Ctrl+字母 / F 键），而这几条是**输入框内**的导航键 ——
* 它们只有在焦点在这个输入框里时才有意义。
* `keyboardShortcut` 是"无论焦点在哪都响应"，用在这里会让
* Enter 在页面任何地方都去改收件人。
*/
private onToKey(e: KeyEvent): void {
if (e.type !== KeyType.Down) {
return;
}
if (!this.suggestOpen || this.suggestItems.length === 0) {
return;
}
if (e.keyCode === KeyCode.KEYCODE_DPAD_DOWN) {
this.suggestActive = nextActiveIndex(this.suggestActive, this.suggestItems.length, 1);
} else if (e.keyCode === KeyCode.KEYCODE_DPAD_UP) {
this.suggestActive = nextActiveIndex(this.suggestActive, this.suggestItems.length, -1);
} else if (e.keyCode === KeyCode.KEYCODE_ENTER || e.keyCode === KeyCode.KEYCODE_TAB) {
if (this.suggestActive >= 0 && this.suggestActive < this.suggestItems.length) {
this.applySuggestion(this.suggestItems[this.suggestActive]);
}
} else if (e.keyCode === KeyCode.KEYCODE_ESCAPE) {
this.suggestOpen = false;
}
}
aboutToAppear(): void {
const ctx = this.getUIContext().getHostContext();
@ -366,16 +496,46 @@ export struct ComposeView {
Divider().color(Theme.border)
}
// 收件人
// 收件人（带三段式补全；键盘 ↑↓ 切换、Enter/Tab 选中、Esc 收起）
Row() {
Text('收件人').fontSize(14).fontColor(Theme.textSubtleFor()).width(60)
TextInput({ placeholder: 'name@path.session', text: this.to })
.layoutWeight(1).fontSize(14).backgroundColor(Color.Transparent)
.onChange((v: string) => { this.to = v; })
.onChange((v: string) => { this.onToChanged(v); })
.onKeyEvent((e: KeyEvent) => { this.onToKey(e); })
.onBlur(() => { this.suggestOpen = false; })
}
.width('100%').height(48).padding({ left: 12, right: 12 })
.backgroundColor(Theme.surface)
/*
* 候选列表 —— 贴在收件人行**下方**（WebUI `AddressInput` 的绝对定位菜单）。
*
* ★ 为什么不用 `bindPopup`/`bindMenu`：那两者各有自己的焦点体系，
* 用户的按键会先被它们吃掉，"↑↓ 切换候选"就落不到 `onToKey` 上。
* 内联渲染（条件挂载）能让焦点一直留在输入框里 —— 这是键盘可达的前提。
*/
if (this.suggestOpen && this.suggestItems.length > 0) {
Column() {
ForEach(this.suggestItems, (item: string, idx: number) => {
Row() {
Text(item).fontSize(13).fontColor(Theme.textPrimary).layoutWeight(1)
if (idx < this.suggestTitles.length && this.suggestTitles[idx].length > 0) {
Text(this.suggestTitles[idx])
.fontSize(12).fontColor(Theme.textSubtleFor())
.maxLines(1).textOverflow({ overflow: TextOverflow.Ellipsis })
}
}
.width('100%').height(40).padding({ left: 12, right: 12 })
.backgroundColor(idx === this.suggestActive ? Theme.accentSoftFor(this.isDarkNow) : Color.Transparent)
.onClick(() => { this.applySuggestion(item); })
}, (item: string, idx: number) => item + '#' + idx.toString())
}
.width('100%')
.backgroundColor(Theme.surface)
.borderRadius(Theme.glassRadius)
}
Divider().color(Theme.border)
// 主题

76
client/harmony/entry/src/main/ets/pages/MainPage.ets
View File

@ -21,6 +21,7 @@ import { AppearanceStore } from '../common/AppearanceStore';
import { MailStore, MailSnapshot, INBOX_PAGE_SIZE } from '../common/MailStore';
import { AppearanceApi } from '../api/AppearanceApi';
import { performLogout } from '../api/Logout';
import { ComposeIntent } from '../common/ComposeIntent';
import { Configuration, ConfigurationConstant, EnvironmentCallback, common } from '@kit.AbilityKit';
import { image } from '@kit.ImageKit';
import { AppearanceSnapshot, isDarkMode, scrimOpacity } from '../model/Appearance';
@ -90,9 +91,6 @@ import {
NAV_ITEM_MIN_HIT,
NAV_ITEMS,
HEADER_BACK_HIT,
TAB_BAR_RADIUS,
TAB_BAR_SIDE,
TAB_BAR_TOP,
navBadgeCount,
navBadgeText,
navBadgeTone,
@ -1598,6 +1596,20 @@ struct CommPage {
@State currentMailId: string = '';
aboutToAppear(): void {
/*
* ★ 2in1 快捷键的**接手方**（用户 2026-09-21：「快捷键打开发信页面」）。
*
* 本页是**条件挂载**的（`if (this.currentIndex === 0)`）⇒ 用户按键时它
* 可能还没实例化。所以两半都要有：
* · 登记监听 —— 用户此刻就在通信页时，当场响应；
* · `consume()` —— 用户此刻在别的页时，请求存在格子里，
* 本页挂载后立刻取走（否则按了快捷键一切换页面就该弹写信，
* 却因为"没人在听"而丢掉）。
*/
ComposeIntent.setListener(() => { this.openCompose(); });
if (ComposeIntent.consume()) {
this.openCompose();
}
this.refreshCounts();
/*
* ★ 注册"点通知要跳转"的回调（2026-09-17 真机实测补的**另一半**）。
@ -1615,6 +1627,9 @@ struct CommPage {
}
aboutToDisappear(): void {
/* 摘掉快捷键监听 —— 否则会唤醒一个已销毁的组件 */
ComposeIntent.clearListener();
// 必须摘掉：留着会叫醒一个已销毁的页面（跳转落空，还容易误判成"推送坏了"）
PushService.clearRouteListener();
}
@ -3480,6 +3495,19 @@ struct MainPage {
* ⑤ §7.12 的「材质（玻璃）」行原本写的就是固定档 ⇒ (a) 是**回到**已登记契约。
* 产品向还有一条：**导航条是 chrome，材质应当稳定**，不该因为用户换了一张壁纸而变厚变薄。
*/
/*
* ★★ 2026-09-21 **底栏改成参数化玻璃**（用户：「玻璃也不透明」「不够炫酷」）。
*
* 底栏是 WebUI 里 `backdrop-filter` 的两个位置之一，
* 且数值最大的一处（`.narrow-nav`：`blur(18px) saturate(1.5)`，
* `index.css:1204`）。`saturate` 才是"玻璃感"的主旋钮 ——
* 透过玻璃的颜色被提亮，而固定材质档没有这个旋钮（观感偏灰）。
*
* `backgroundEffect` 取代 `backgroundBlurStyle`（两者都调会叠加：
* 那不是"更玻璃"，而是两层各采样一次背景 ⇒ 更脏更糊 + 滚动掉帧）。
*
* 数值全部来自 `Theme.navGlassEffect()` —— 不在调用点写死。
*/
.backgroundBlurStyle(Theme.navMaterial)
}
.width('100%')
@ -3887,5 +3915,47 @@ struct MainPage {
this.isWide = (newValue.width as number) >= 768;
this.recomputeNavReserve();
})
/*
* ★★ 2in1 快捷键（用户 2026-09-21：「接下来做一下 2in1 上的快捷键，
* 比如快捷键打开发信页面」）。
*
* 用官方的 **`keyboardShortcut`（组件快捷键事件，API 10+）**，
* 而不是自己 `onKeyEvent` 收 Ctrl+字母。理由（官方 API 文档原文）：
* · 「即使组件未获焦或是在所在页面未展示，只要已经挂载到**获焦窗口**
* 的组件树上就会响应自定义组合键」
* · 「无论组件是否获焦 —— 只要窗口获焦，快捷键就会响应」
* 自己收 onKeyEvent 则要**先让某个组件获焦**，而邮件列表里焦点落在哪
* 是不确定的（点一下就换），快捷键会时灵时不灵。
*
* 绑定位置选**根 Stack**：它是"整个 window 的组件树"的根，
* 只要窗口在就生效。绑在 FAB 上不行 —— FAB 在别的 `if` 分支里、
* 窄屏/宽屏位置也不同，它会随分支挂载/卸载。
*
* 键位选 `Ctrl+N`：官方文档给了硬约束 ——
* 「控制键 Ctrl、Shift、Alt 及它们的组合加上热键的单个字符」，
* 而禁止绑定的五个系统组合键（Alt+F4 / Alt+Tab / Ctrl+Shift+Esc 等）
* 都不含 Ctrl+N。写邮件在桌面端历来是 Ctrl+N（新窗口/新邮件），
* 迁移成本最低。
*
* ★ 文档还有一条要记住的坑：「多个不同组件设置相同组合键 ⇒
* **只响应节点树上的深度最浅的组件**，其它组件不响应」。
* 所以别再给别处的"写信"按钮补一个同键位绑定 —— 那不是"多一个入口"，
* 而是**让这一处失效**（浅的那个永远赢）。
*/
.keyboardShortcut('n', [ModifierKey.CTRL], () => {
/*
* ★ 这里**不能**直接叫 `openCompose()`：根组件是 `MainPage`，
* 而 `openCompose()` 住在 `CommPage` 上（写信要用 `CommPage` 自己的
* `navPathStack`，宽屏 Split 才能在右栏开）。
*
* 两步：
* ① 把通信页切到前台 —— 否则用户此刻若在日历页，
* `CommPage` 因条件挂载还没实例化，没有监听者；
* ② 提"要写信"的意图，由 `ComposeIntent` 负责
* "此刻有人听就当场给、没人听就存着"。
*/
this.currentIndex = 0;
ComposeIntent.request();
})
}
}