|
|
477479a370
|
fix(harmony): ★★ 三页 AppHeader 顶栏避让硬编码 0 ⇒ 顶栏压进系统状态栏（真机实测）
设备：HUAWEI MatePad Pro（MRDI-W00），HarmonyOS NEXT，API 26，
`hdc tconn 192.168.2.87:43679`（此前一直无真机，本条挂了 5 天）。
## 症状（用户报：「左上角全屏状态下不应该显示全屏，会与顶部系统顶栏冲突」）
截图像看是状态栏压住顶栏。**实测证伪了这个读法**：像素扫描 + `uitest dumpLayout`
显示顶栏文字在 y=134..166、系统状态栏止于 y=82，**两者不重叠**。
真正被切掉的是**列表第一封邮件的标题**（y=294..319，只剩一条细线）。
⇒ 两处独立问题，第二个（窗格头 y=222..320 与列表首行 y=294..319 重叠）
**不是顶栏避让**造成的，本次未修，见下。
## 已修：AppHeader 那一半的避让确实是坏的
`EntryAbility` 早就把避让读到了（真机日志 `insets: statusBar=38.588235
navIndicator=27.764706 windowDecor=37`），`CommPage`/`MainPage` 内容层也用了
（`top: max(statusBar, windowDecor) + paneGap`）。**但 `AppHeader` 是另一个消费者，
三处都写死了 `topInsetPx: 0`**：
· `SentTab`（发件箱） MainPage.ets:1658
· `SettingsPage`（我的） SettingsPage.ets:687
· `PermissionTab`（授权） PermissionTab.ets:487
只有 `AdminUsersPage` 是对的（`topInset(this.windowInsets)`）—— 抄它。
## 为什么已有的判据没抓到（这才是关键）
`harmony-window.test.mjs` 接线⑤「每一个 @Entry 页都要消费避让」是**绿的**，
因为它的 `consumes()` 认两种形状，其中一种只要**文件里出现过**
`this.windowInsets.statusBar` 就算过 —— 而 `MainPage` 的**内容层**正好读了它。
⇒ 页面上有**两个**避让消费者，判据只问"页里有没有出现过那个字段"，
于是 `AppHeader` 里那个 0 被完全放过。
新判据（判据 10）改成**逐个消费者问**：任何传给 `AppHeader` 的 `topInsetPx`
不得是字面量 0。自检要求扫到 ≥4 处，防"遍历写错 ⇒ 永远绿"。
★ 这条判据自己先犯过一次同类错并当场被抓：第一版用 `prose()`（含注释），
把**我自己写进注释里的**「原先 topInsetPx: 0」抓成了红 ——
判据在判自己的注释。改用本文件已有的 `stripped()`（其注释原话：
「判据的锚不能落在被守对象的自述上」）。红绿已验：把 SettingsPage 退回
缺陷版 ⇒ 红；恢复 ⇒ 绿。
## 编译期抓到的一个坑
`MainPage.ets:1658` 的 AppHeader 在 **`SentTab`** 里，而 `windowInsets` 原本
只声明在 `CommPage` 上。ArkTS 报 `Property 'windowInsets' does not exist on
type 'SentTab'`。⇒ `@StorageLink` 是**每个组件各自**订阅 `AppStorage` 的，
父组件的不会自动传给子组件；直接各自订阅同一把键（比"父传子"少一层）。
## 真机验证
装机后重跑 dumpLayout：发件箱顶栏 `y=134..166`（状态栏底 y=82，间隙 52px），
截图确认「发件箱」完整显示、不再被压。
## 未修（诚实登记）
列表第一行标题被窗格头盖住（`List` 首项 y=294..319 落在窗格头 y=222..320 内），
与顶栏避让**无关**，本次未动。根因待查：`MailRow` 是 `.height(64)` 定高，
而 List 容器从 y=320 起算，首项被画到容器上方。
|
2026-10-01 18:49:06 +08:00 |
|
|
|
f0dc342c1f
|
鸿蒙｜图标 fill 型分族 + 页签条阴影根因修复 + 生成器入库
用户逐条报的观感问题（都在"视觉观感"那一栏，不是功能缺失）：
① 侧边栏图标"莫名其妙的加粗"
根因：43 个图标里**只有品牌标 `brandMark` 是 fill 型**
（`fill="currentColor"` + 两个实心 `<circle r=".9">`），
它自己的注释就写着「fill 型，与上面的描边图标集**不同族**，所以不包 Svg」。
而 `AmIcon` 一律 `fill(Transparent) + stroke()` ⇒ 实心块只剩轮廓、
实心眼变成小圆环、圆头端点在小尺寸下糊成一坨。
修法：生成器自动判定两族（`is_fill_family`），产出 `FILL_ICONS` 名单，
fill 族整块填色、不加描边。
② 详情页权限面板"左边被截断"
`PermissionPanel` 挂在详情页外层，根部只有 `padding({top:10})` ——
而正文 `Markdown` 与附件块**各自自带** `left/right:16`。补上同档 16。
③ 顶栏"莫名其妙的底部阴影"
★ 这条查错了两轮，记下来：
· 先以为是窗格投影从半透明玻璃透上来 → 补底边、去材质 —— 都没用；
· 几何取证才定位真因：`InboxTab` 根容器与页签条是 `Column` 里的**兄弟**
且**绘制在后**（页签条 y 142→271，InboxTab y 271→2202），
它的 `PaneModifier` 投影向上扩散 ~30px，正好压住页签条
（观测到的渐变区 y 240→268，完全吻合）。
· 双向验证：关掉所有窗格投影 → 全平（证明确实是投影）；
只把 `InboxTab` 换 `plain` → 落差 21→8（证明是**这一层**）。
修法：`PaneModifier` 加 `plain()`（只要背景语义、不投投影）。
WebUI 的 `box-shadow` 只给 `.app-shell > *`（三个**并列**面板），
面板内部不投 —— 这个结构差异就是原因。
★ 同时保留页签条的**悬浮玻璃**（用户 09-20 点名要的）：
我中途一度按"跟 webui 同步"把它改成不透明实体面，
那是**读错了**——用户指的是页面结构对齐，而玻璃是他自己定过的；
两者不冲突（玻璃是观感选择，阴影是 bug）。已恢复并留注释。
④ 生成器入库（`client/harmony/tools/gen-icons.py`）
它原先在仓库外（`/root/gotmp`），于是**落后生成物三次提交**没人发现：
我手改 `Icons.ets` 修 fill 图标后重跑它，修改被**冲掉**（退回旧实现）。
现在：路径按 `__file__` 解析（任何检出目录都能跑）、
`is_fill_family` 自动分族、输出段与正确实现逐字一致（diff 为空）。
`Icons.ets` 由它生成，不再手改。
判据：
· `harmony-appearance` 29 条（+1）：窗格投影只给并列窗格，
面板内部的子 tab 不得再投。按 **struct 归属**判（第一版计数有洞，
变异①抓不到 —— 改回 `of` 时同文件别处的 `plain` 仍让它绿）。
两个变异都能红：① InboxTab 改回 of；② 让 plain 也投投影。
另修一条既有判据的假红：它数 `PaneModifier.of` 出现次数，
加 `plain` 后误报（"让出页面底"的两种合法写法都要算）。
· 套件：harmony-nav 22/22、harmony-appearance 28/28、
harmony-logic 34/34、harmony-contacts 5/5、animation-audit 15/15。
**功能对齐状态**（回答用户"功能对齐没有"）：
对着 `docs/DEBTS.json` 逐条核过 —— 鸿蒙侧**没有缺页面、没有缺功能**。
授权栏历史（`harmony-permission-history`）✅ 已做、
详情页转发/改名建议/预算（`harmony-maildetail-missing-three`）✅ 三块全做完。
仅剩两条，都不在鸿蒙：`harmony-p4c-boundary-decls` 卡在"需真人操作系统选图器"、
`permission-expires-at-unused` 缺的是 **WebUI 那一半**。
|
2026-09-24 13:13:46 +08:00 |
|
|
|
65de1c3884
|
跨端对齐：授权栏 navigator_only + 组件按页拆分 + 服务器补 permission_options
用户两项裁定落地（均为 ask_user 明确选择）：
① 授权栏口径 = navigator_only（照 WebUI 架构）
· 新建 pages/PermissionPanel.ets —— 详情页的决策面板，
对应 MailView.tsx:693 的 PermissionPanel（审批型 / 主动提问 / 已处理 三态）
· 决策入口从授权栏移到 MailDetailPage；MailDetailPage 原来只显示一个
「权限请求」小标签、根本没有决策入口（比 WebUI 少一整块，且反了：
栏里能决策、点进详情反而不能）
· PermissionTab 删掉内联「同意/拒绝」+ 备注框 + decide()：
整卡可点 → onOpenMail（对齐 WebUI PermissionList.tsx:81 的 pick()）
· PermissionRequest 补 source_account_id（客户端侧记来源，跳详情要定位网关）
② 服务器补 permission_options —— 修一条真实的、跨端共有的缺口
· mails.permission_options 从 INSERT 起就写进去，但**从来没有任何读路径
选过它** ⇒ 详情端点永远返回空。WebUI 的决策面板读 mail.permission_options，
所以提问型的预设选项**两端全部落空**（审批型靠 ['同意','拒绝'] 兜底蒙混）
· GetMailByID 补选该列 + JSON 反序列化（与 cc_list 同款）
③ 组件按页封装（用户要求「以便与 WebUI 一一对应」）
MainPage.ets 4592 → 3192 行
· pages/PermissionTab.ets 720 行 ↔ PermissionList.tsx
· pages/ContactsTab.ets 796 行 ↔ ContactPanel.tsx
· pages/NavDestinations.ets 181 行 ↔ Navigation 壳
· pages/NavShared.ets 65 行 ↔ 跨栏共用件
④ 判据跟着组件搬家（否则静默失效，不是红）
harmony-logic 的 pageCode / harmony-nav 的 navSrc 改为显式文件名单；
harmony-appearance 的 PANE_SOURCES 补 ContactsTab；harmony-contacts 三个
test 并入 ContactsTab；harmony-logic 的决策断言改指 PermissionPanel，
并新增「授权栏不许再有内联决策」两条（navigator_only 的正形状）。
animation-audit：共享元素转场判据从「同文件共址」改为「按 id 找驱动」。
旧形状把 in/out 端必须在同一文件当成代理，而两端**天然在两处**；
抽出写信页（NavDestinations 持有 in 端）后误报。新判据仍要求每个 id
都有 Motion.morph 驱动 —— 变异实测：把驱动换成裸 animateTo 仍判红。
判据：files=34 checks=556 red=1（仅 build-stamp，产物待重构建）
|
2026-09-24 10:10:32 +08:00 |
|
