A
Air官方
【Air 系列 · 鸿蒙 PC 适配全记录】47 / 56
■ 应用：AirSlicer（AirSlicer）
■ 定位：OrcaSlicer 移植，3D 打印切片
■ 上游：OrcaSlicer ｜ 路线：wxGTK3+GTK3 栈 ｜ 版本：1.0.0
■ 开源： https://gitcode.com/Andy88/Harmony-OrcaSlicer
■ 市场状态：开发中，即将上架
■ 官网（免费下载）： https://www.shunidc.cn/
————————————————————
开源鸿蒙 PC 社区： https://harmonypc.csdn.net/
PC 社区项目申请： https://atomgit.com/OpenHarmonyPCDeveloper
适配开源地址：https://gitcode.com/Andy88/Harmony-OrcaSlicer
环境搭建文章：https://blog.csdn.net/weixin_52908342/article/details/161343743
▍一、为什么要适配 AirSlicer
OrcaSlicer 是 Bambu Studio 系的开源 3D 打印切片器：模型导入与排版、工艺参数配置、切片预览与 G-code 生成，是桌面 3D 打印工作流的中枢软件。它的 GUI 建立在 wxWidgets 之上，叠加 OpenGL 视口、OCCT 几何、CGAL 与 OpenVDB 等重型依赖，属于桌面软件里移植难度最高的一类。把这样的软件带到鸿蒙 PC 与平板上，意味着 3D 打印用户可以在鸿蒙设备上完成从模型文件到切片产物的完整环节。
AirSlicer 是 OrcaSlicer 上游 main 快照的鸿蒙原生移植工程，严格参照兄弟项目 AirEDA（KiCad 8 / wxWidgets 路线）与 AirCad（FreeCAD / 3D 栈）的方法论：ArkTS 壳加 XComponent(TEXTURE)，核心侧以 wxGTK 3.3.2（Orca fork）叠加 AirEDA 的 GTK3 OHOS 栈，3D 视口走 wxGLCanvasEGL 加 GLES3 的 pbuffer/FBO 读回，再由 GDK OHOS 后端统一上屏。工程档案从 2026-08-26 起逐轮记录：MatePad 11.5、MatePad Mini 与 MateBook Pro 2in1 三种设备上的部署、12 用例验收、以及数十个根因的破案过程。
当前工程包名 com.airslicer.app，版本 1.0.0，deviceTypes 覆盖 phone、tablet 与 2in1，ability 为 singleton 启动模式，声明 ohos.want.action.sendData（maxFileSupported 8）与 viewData 文件接收入口，申请 ohos.permission.READ_PASTEBOARD 剪贴板权限。Native ABI 为 arm64-v8a，核心动态库 liborcaslicer_ohos_core.so 约 82MB，闭包依赖经 entry/libs/arm64-v8a 通道打包。
▍二、先划清边界：不把编译通过当成适配完成
OrcaSlicer 原生是带窗口管理器协同的桌面应用：系统菜单栏、桌面文件对话框、WM 窗口装饰、剪贴板互操作都由桌面环境提供。鸿蒙侧既无 X11/Wayland 也无 WM，这些环节必须逐一重新落位。工程用 S1 到 S14 的强制标准逐项审计，并把"缺口不宣称完成"写成纪律：native 冻结期内无法实现的手写笔、光标钩子等项如实标注缺口，而不是用界面相似度顶替功能交付。
层次 原项目实现（桌面 Linux） 鸿蒙侧当前方案
应用入口 桌面 main() 进程 Stage 模型 EntryAbility，单进程 wxApp，core so 由 NAPI 桥 dlopen
窗口承载 X11/Wayland + WM 装饰 XComponent(TEXTURE) + GDK OHOS 后端合成，自绘标题栏
3D 视口 桌面 GLX 上下文直绘 wxGLCanvasEGL：pbuffer/FBO 渲染 → glReadPixels → cairo 上屏
菜单系统 wxMenuBar 挂接 WM ArkTS 静态命令表 + 快捷键序列注入（上游已用 BBLTopbar 取代 wxMenuBar）
文件对话框 GTK 原生对话框 ShowModal 拦截 → DocumentViewPicker 三模式 + 沙箱 staging 回拷
手写笔 平板硬件透传 NDK 无 PEN 源类型与 tilt 通道，登记为缺口待重评估
暗黑模式 GTK 主题 壳层钉死深色 + conf dark_color_mode 幂等改写，重启保持
表格中的每一行都有真实代码与验证记录对应。特别是菜单一行：上游 Orca 2.x 已经用自绘 BBLTopbar 取代了 wxMenuBar（GetMenuBar()==null 实证），原计划的 wxMenuBar→JSON 菜单桥架构性失效，工程据此改为 ArkTS 侧静态命令表承接，这个转折在档案中有完整记录。
▍三、鸿蒙版的整体架构
工程采用 Air 双层架构的 GTK 变体：ArkTS 壳层（NativeHost 页面）负责 XComponent 宿主、菜单栏、沉浸式管理与分享接收；薄 NAPI 桥 liborcaslicerbridge.so 承接组件回调、拓扑序 dlopen、就绪协议与对话框分流；core 侧 liborcaslicer_ohos_core.so 内含 OrcaSlicer main 的改写入口 orcaslicer_ohos_main，驱动 wxGTK 全家与 GTK3 OHOS 栈；Boost、TBB、OCCT、Python、OpenVDB、CGAL、OpenCV 等闭包依赖全部经 entry/libs 通道随包分发。
text
EntryAbility / NativeHost.ets（ArkTS 壳）
├── XComponent(TEXTURE) + 沉浸式管理（ImmersiveManager FLOATING/MAXIMIZE 分流）
├── ArkTS 菜单栏（文件/切片/工具/选项）+ 快捷键注入通道
├── 分享与碰一碰接收（ShareManager + harmonyShare dataReceive）
└── 对话框子窗口治理（DialogPage + DialogWindowManager）
▼ NAPI：liborcaslicerbridge.so（拓扑序 dlopen + 触摸/键盘/轴分发）
liborcaslicer_ohos_core.so（orcaslicer_ohos_main：gtk_init → wxEntryStart）
├── wxGTK 3.3.2 全家（base/net/xml/core/adv/aui/html/propgrid/richtext/stc/gl[EGL-OHOS]）
├── GTK3 栈（AirEDA gtk-stack，GDK OHOS 后端 + dialog subwindow ops）
└── Boost 1.85 / TBB / OCCT 7.8.1 / Python 3.11.9 / OpenVDB / CGAL / OpenCV 闭包
主要目录如下：
text
AirSlicer/
├── AppScope/app.json5 # com.airslicer.app、版本
├── PORTING.md # 移植档案：选型、补丁登记、风险与逐轮记录
├── native/scripts/ # env.sh、build_boost/wx/orca、deploy_orca、relink_full_core
└── entry/src/main/
├── module.json5 # sendData/viewData skills、READ_PASTEBOARD
├── ets/
│ ├── pages/NativeHost.ets # XComponent 宿主、静态菜单、V2 状态管理
│ ├── pages/DialogPage.ets # 对话框子窗口页（标题条拖拽/回写）
│ ├── components/ImeBridge.ets # 输入法桥
│ ├── managers/ImmersiveManager.ets # 沉浸式与自由多窗路由
│ └── utils/ # DialogWindowManager、FileManager、ShareManager
└── cpp/
└── napi_init.cpp # 薄 NAPI 桥：事件分发与通道
▍四、核心适配过程
### 1. 复用优先的依赖矩阵
工程把依赖分成三类处理：现成复用（AirEDA 的 GTK3 OHOS 栈、AirCad 的 OCCT 7.8.1 与 Python 3.11.9、AirRaw 的 libcurl）；源码自编（Boost 1.85 全 13 组件、OpenSSL 1.1.1w、TBB、CGAL 5.6.3、OpenVDB 全套、OpenCV 4.6 最小集、wxWidgets 3.3.2 Orca fork）；上游随构（imgui、libnest2d、clipper2 等树内依赖）。wxWidgets 的交叉构建打出 W 系补丁：configure 的 X11 链接置空、glegl 实现 OHOS GL canvas、filedlg/dirdlg 拦截改系统选择器、wxFrame 菜单栏隐藏。这套矩阵让约三十个第三方依赖在可控成本下进入闭包，构建链脚本（native/scripts/ 下 build_boost 到 deploy_orca 九步）按序可复现。
### 2. 3D 视口的 GLES 读回合成
鸿蒙侧没有窗口系统 GL 表面，工程利用 Orca 自带的 SLIC3R_OPENGL_ES 全量 GLES 路径：wxGLCanvasEGL 在 OnRealized 时建立 pbuffer，SwapBuffers 改为 glReadPixels 读回像素，GTK draw 回调里经 cairo ARGB32 上屏，含垂直翻转与 BGRA/GL_RGBA 通道探测。O 系补丁补齐 ES 上下文版本（EGL_CONTEXT_CLIENT_VERSION=3）、全局 SLIC3R_OPENGL_ES 宏定义，并修复了 libvgcode 的 ES 分支烂尾（Prusa SPE-2411 的 Vec3→Vec4 未同步、RGB32F 纹理在 GLES3 不存在等），冷启动 GLSL 报错弹窗在双机实证消失。渲染链早期还经历了七层破局：ES3 上下文强制、HasWindow 的 OHOS 语义、36 件 ES shader 资产自动转换、675 个桌面 GL 桩符号生成，最终 Maleoon GPU 真渲染打通。
### 3. 文件通道：选择器桥与分享接收
原生 GTK 文件对话框无桌面环境可用，W4/W5 补丁把 wxFileDialog 与 wxDirDialog 的 ShowModal 拦截，经 NAPI 转发到系统 DocumentViewPicker，支持 open/save/dir 三模式、后缀过滤、URI 到沙箱的 staging 中转与保存回拷同步守护。分享接收声明了 sendData/viewData 两个 skill 入口，want 带入文件经 fd 嗅探或 URI 中转进入 pendingOpen，配合 Ctrl+I 自动应答；碰一碰通过 harmonyShare dataReceive 注册。导入链经历九轮闭环：壳层链路先验证 100% 走通，再由源码定位出 native 侧 GetPaths 空数组静默早退的真正根因（见难点一），最终导入、落板、可重复得到实证。
### 4. 输入双模与触控补偿
触摸与鼠标双模分流：合成触摸源（鼠标/触控板）只取 MOVE 转光标，手指走全通道；OH_NativeXComponent 局部坐标与 GDK root 原点间的 +8.4px 固定残差用九连击像素测量定案并补偿。捏合缩放实现三源：滚轮轴、手指双指状态机（第二指落下对首指补 CANCEL、log2 距离比累积阈值转滚轮步进）、触控板 pinch 轴。对话框场景另建拖拽转滚轮通道：对话框内触摸拖拽超过 24px 转为滚轮步进注入，解决 GTK scrolledwindow 不吃鼠标拖拽而平板无滚轮的死结，真机验证滚动可达列表末尾且无伪点击。
### 5. 汉化、暗黑与布局治理
汉化走三通道：conf 的 app 节 language=zh_CN（真通道，此前顶层注入被忽略是首败根因）、dlopen 前置的 LANGUAGE/LANG 环境变量、rawfile 自带的 OrcaSlicer.zh_CN.mo 与 wxstd.mo。暗黑模式由壳层 setColorMode 钉死、conf dark_color_mode 每代启动幂等纠正。布局治理则是一组持久战：ui_scale 只放大字体而 em_unit 不随动导致固定行高裁切，工程以页签字号降档、行高分档上调、TabCtrl 间距收缩三处落补丁，DPI 2.5 档三处裁切全部关闭。
▍五、适配中遇到的几个难点
### 难点1：导入落板"轮盘"的九轮闭环
分享导入的文件应答送达后模型却不上板，早期表现为时好时坏，被称作"轮盘"。壳层先排除自身：knockFile 到 pendingOpen 到 W4 拦截到自动应答全链探针实证无损。破案最终落在 W4b：wx 文件对话框拦截态只回填了 GetPath 单数版本，而 Orca 的导入路径走 GetPaths 复数版本——无 widget 的 GTK chooser 在拦截态返回空数组，Plater::add_file 第一行的 empty 检查静默早退，先于任何日志，与"零报错零加载"完全吻合。补齐 GetPaths/GetFilenames/GetDirectory 三函数回填后随 wx 全量重建生效，STL 对象信息（20x20x20mm、12 三角形、零错误）逐字实证。这轮的教训是：静默失败必须下探到上游源码的早退分支，壳层探针齐全也只能证明自己无辜。
### 难点2：GL 视口错位的部署链无声降级
某轮构建后 3D 视口整体偏移约 500px，场景左半幅被截取。排查链覆盖了缩放、最大化、布局钳制后，GLSize 探针锁定单位量纲：Orca 在 ENABLE_RETINA_GL 下按 retina 因子取景，场景渲进了逻辑尺寸一半的 pbuffer。根因不在代码而在部署脚本：deploy_orca.sh 从 AirPhoto 构建树拷贝定制 libgdk，该树被删后静默回落到旧版本（scale 恒 2），单位翻面回归。修复三件套为后端权威源加回 GDK_OHOS_SCALE 读取、gtk3 全量重编、wx 增量重编对齐换算。这个案例的教训被写进档案：构建产物的静默降级比代码缺陷更难查，env 脚本失效要连接到症状面。
### 难点3：em_unit 膨胀挤窄 3D 画布
侧栏参数面板莫名膨胀到 585 DIP（基线 215），3D 画布被挤压。定位发现侧栏 AUI 面板的 BestSize 按 39 乘 em_unit 计算，而 em_unit 取自 GetTextExtent("m") 减一，在 OHOS 上恒为 15，与 ui_scale 无关，字体渲染正常但 extents 疑似物理逻辑双计。仅封顶面板 BestSize 无效（内容最小宽链把面板推回），最终在 update_em_unit 处封顶 10 生效，画布恢复。这类问题展示了 wx 布局体系对字体量测的深依赖，一个单位的量测偏差会沿布局链放大成整栏位移。
### 难点4：滚动失效假象与坐标系误判
参数面板被报告"滚动失效"，三轮补丁（FitInside、SetMinSize、SetClientSize）均无效。全树转储揭露真相：所有页签内容实际高度都装得下 905 视口，"内容超出视口底"是把 1381 逻辑像素当物理屏底的误判（窗口顶部还有 219 物理像素的状态栏偏移），y 大于 1600 的区域像素一致属帧缓存残影。破案后工程保留一个防御性安全网（换页后取后代真实底边、超视口时恢复滚动范围）应对专家模式等长内容场景，并把六类诊断探针全部清零、三库干净重编后交付。这个难点说明视觉表象必须先过坐标系审计，再动布局补刀。
### 难点5：上游确定性崩溃与对话框治理
全新安装后点击打印机下拉空白行必现 SIGSEGV。崩溃栈收敛到上游 on_select_preset 的确定性缺陷：get_similar_printer_preset 返回 nullptr 时弹出空 MessageDialog 提示，上游漏写 return，对话框栈析构后继续解引用空指针。补丁补上 return 并把空标题改为可识别文案，九次以上触发态复测零崩溃。对话框体系本身也经历系统治理：无 WM 环境下的多实例弹窗走 GDK 子窗口模式，标题条拖拽实现双通道（Touch 同步 startMoving 加 PanGesture 兜底）、拖拽回写 GTK 记账防隐形矩形死区、用户手动搬移后 tick 越界让渡主权，避免应用与用户"抢窗口"。
▍六、编译、安装与启动
Native 侧按 native/scripts/ 的固定顺序构建：env.sh 载入交叉环境（内置 PATH 前置 /usr/bin 防 diff 劫持、ohos-ld shim、elf_edit 原位编辑等工具坑对策），依次执行 build_boost、build_ssl_gmp_mpfr、build_small_deps、build_big_cmake_deps、build_openvdb、build_wx、build_orca，最后 deploy_orca.sh 收集闭包、NEEDED 去版本号并部署 rawfile 资源。ArkTS 与 HAP 打包使用标准 hvigorw 流程：
bash
export JAVA_HOME=/Applications/DevEco-Studio.app/Contents/jbr/Contents/Home
export DEVECO_SDK_HOME=/Applications/DevEco-Studio.app/Contents/sdk
hvigorw --mode module -p module=entry assembleHap --no-daemon
签名产物位于：
text
entry/build/default/outputs/default/entry-default-signed.hap
连接设备后安装并启动：
bash
hdc install -r entry/build/default/outputs/default/entry-default-signed.hap
hdc shell aa start -a EntryAbility -b com.airslicer.app
仅改动 ArkTS 或 napi 桥时，可跳过 native 链直接 hvigor 构建；档案记载的部署循环为 deploy_orca.sh 后接 devecocli build 与 devecocli run。2026-09-06 的 native 全链重建（新 wx 与新 core）后，冷启动约 12 秒进入完整深色中文主界面，导入、落板、页签巡检均有截图留痕。
▍七、当前功能边界
当前鸿蒙版已覆盖的能力（S1 到 S14 审计表的通过项）：
- 冷启动完整主界面：深色全中文、参数面板全量、3D 视口平台网格与坐标轴渲染、TabKick 自动激活 Plater 页；
- ArkTS 菜单栏与快捷键命令链（Ctrl+N/O/I/S/R/G/J/F/P 与 Shift 组合，对照上游 CHAR_HOOK 表）；
- 系统文件选择器三模式（打开/保存/目录）与后缀过滤、URI staging 回拷、文件夹授权与镜像同步守护；
- 分享与碰一碰接收、导入落板可重复（STL 对象信息逐字实证）、BBL 预设 59 机型加载；
- 触控与鼠标双模、双指捏合三源缩放、对话框拖拽滚动通道、+8.4px 坐标补偿；
- 全面汉化三通道、暗黑模式钉死与重启保持、剪贴板入向（权限动态申请与事件驱动）。
尚未覆盖或登记为缺口的能力（均有档案依据）：手写笔压感与倾角（NDK 无 PEN 源类型，待 native 重评估）；光标样式跟随（libgdk-3 无变化钩子）；剪贴板出向（后端仅暴露入向符号）；切片与保存工程的真手指端到端（通道就绪，自动化受注入工具限制待人工验证）；Monitor 设备监控页签（无网络通道，已裁剪）；自由窗下的队列子窗重显残影与恢复对话框打断首绘两项观感缺陷；短拖死区约 48px 的手势启动损耗。
因此，当前版本更准确的定位是"OrcaSlicer 鸿蒙原生移植的三设备验证版"：主界面、导入、预设与输入主链路在 MatePad 11.5、MatePad Mini 与 MateBook Pro 上实证，输出环节与少数外设通道如实登记为待验与缺口。
▍八、总结
AirSlicer 是 Air 系列里依赖最重、桌面耦合最深的一例：wxWidgets 界面体系、GLES 读回渲染、GTK 栈对话框、闭包级依赖矩阵全部要在无 WM 环境里重新落位。工程的价值不在单点突破，而在方法论的可复现：S1 到 S14 标准审计把"完成"定义成可检查项，补丁登记表让每个 W/O/A 系改动可回溯，逐轮档案把每个"复现不了"的现象收敛成根因链。导入轮盘与视口错位两个案例分别示范了源码早退分支取证与部署链静默降级排查，都是可迁移的破案范式。
后续工作的重心沿着档案中的挂账展开：切片与保存的真手指端到端验收、手写笔通道在 native 重建后的重评估、子窗残影与恢复对话框两项观感治理、以及短拖死区的校准。每一步延续同一纪律：以真机行为与截图留痕为验收依据，缺口不宣称完成，边界随重建与验证动态更新。
■ 应用：AirSlicer（AirSlicer）
■ 定位：OrcaSlicer 移植，3D 打印切片
■ 上游：OrcaSlicer ｜ 路线：wxGTK3+GTK3 栈 ｜ 版本：1.0.0
■ 开源： https://gitcode.com/Andy88/Harmony-OrcaSlicer
■ 市场状态：开发中，即将上架
■ 官网（免费下载）： https://www.shunidc.cn/
————————————————————
开源鸿蒙 PC 社区： https://harmonypc.csdn.net/
PC 社区项目申请： https://atomgit.com/OpenHarmonyPCDeveloper
适配开源地址：https://gitcode.com/Andy88/Harmony-OrcaSlicer
环境搭建文章：https://blog.csdn.net/weixin_52908342/article/details/161343743
▍一、为什么要适配 AirSlicer
OrcaSlicer 是 Bambu Studio 系的开源 3D 打印切片器：模型导入与排版、工艺参数配置、切片预览与 G-code 生成，是桌面 3D 打印工作流的中枢软件。它的 GUI 建立在 wxWidgets 之上，叠加 OpenGL 视口、OCCT 几何、CGAL 与 OpenVDB 等重型依赖，属于桌面软件里移植难度最高的一类。把这样的软件带到鸿蒙 PC 与平板上，意味着 3D 打印用户可以在鸿蒙设备上完成从模型文件到切片产物的完整环节。
AirSlicer 是 OrcaSlicer 上游 main 快照的鸿蒙原生移植工程，严格参照兄弟项目 AirEDA（KiCad 8 / wxWidgets 路线）与 AirCad（FreeCAD / 3D 栈）的方法论：ArkTS 壳加 XComponent(TEXTURE)，核心侧以 wxGTK 3.3.2（Orca fork）叠加 AirEDA 的 GTK3 OHOS 栈，3D 视口走 wxGLCanvasEGL 加 GLES3 的 pbuffer/FBO 读回，再由 GDK OHOS 后端统一上屏。工程档案从 2026-08-26 起逐轮记录：MatePad 11.5、MatePad Mini 与 MateBook Pro 2in1 三种设备上的部署、12 用例验收、以及数十个根因的破案过程。
当前工程包名 com.airslicer.app，版本 1.0.0，deviceTypes 覆盖 phone、tablet 与 2in1，ability 为 singleton 启动模式，声明 ohos.want.action.sendData（maxFileSupported 8）与 viewData 文件接收入口，申请 ohos.permission.READ_PASTEBOARD 剪贴板权限。Native ABI 为 arm64-v8a，核心动态库 liborcaslicer_ohos_core.so 约 82MB，闭包依赖经 entry/libs/arm64-v8a 通道打包。
▍二、先划清边界：不把编译通过当成适配完成
OrcaSlicer 原生是带窗口管理器协同的桌面应用：系统菜单栏、桌面文件对话框、WM 窗口装饰、剪贴板互操作都由桌面环境提供。鸿蒙侧既无 X11/Wayland 也无 WM，这些环节必须逐一重新落位。工程用 S1 到 S14 的强制标准逐项审计，并把"缺口不宣称完成"写成纪律：native 冻结期内无法实现的手写笔、光标钩子等项如实标注缺口，而不是用界面相似度顶替功能交付。
层次 原项目实现（桌面 Linux） 鸿蒙侧当前方案
应用入口 桌面 main() 进程 Stage 模型 EntryAbility，单进程 wxApp，core so 由 NAPI 桥 dlopen
窗口承载 X11/Wayland + WM 装饰 XComponent(TEXTURE) + GDK OHOS 后端合成，自绘标题栏
3D 视口 桌面 GLX 上下文直绘 wxGLCanvasEGL：pbuffer/FBO 渲染 → glReadPixels → cairo 上屏
菜单系统 wxMenuBar 挂接 WM ArkTS 静态命令表 + 快捷键序列注入（上游已用 BBLTopbar 取代 wxMenuBar）
文件对话框 GTK 原生对话框 ShowModal 拦截 → DocumentViewPicker 三模式 + 沙箱 staging 回拷
手写笔 平板硬件透传 NDK 无 PEN 源类型与 tilt 通道，登记为缺口待重评估
暗黑模式 GTK 主题 壳层钉死深色 + conf dark_color_mode 幂等改写，重启保持
表格中的每一行都有真实代码与验证记录对应。特别是菜单一行：上游 Orca 2.x 已经用自绘 BBLTopbar 取代了 wxMenuBar（GetMenuBar()==null 实证），原计划的 wxMenuBar→JSON 菜单桥架构性失效，工程据此改为 ArkTS 侧静态命令表承接，这个转折在档案中有完整记录。
▍三、鸿蒙版的整体架构
工程采用 Air 双层架构的 GTK 变体：ArkTS 壳层（NativeHost 页面）负责 XComponent 宿主、菜单栏、沉浸式管理与分享接收；薄 NAPI 桥 liborcaslicerbridge.so 承接组件回调、拓扑序 dlopen、就绪协议与对话框分流；core 侧 liborcaslicer_ohos_core.so 内含 OrcaSlicer main 的改写入口 orcaslicer_ohos_main，驱动 wxGTK 全家与 GTK3 OHOS 栈；Boost、TBB、OCCT、Python、OpenVDB、CGAL、OpenCV 等闭包依赖全部经 entry/libs 通道随包分发。
text
EntryAbility / NativeHost.ets（ArkTS 壳）
├── XComponent(TEXTURE) + 沉浸式管理（ImmersiveManager FLOATING/MAXIMIZE 分流）
├── ArkTS 菜单栏（文件/切片/工具/选项）+ 快捷键注入通道
├── 分享与碰一碰接收（ShareManager + harmonyShare dataReceive）
└── 对话框子窗口治理（DialogPage + DialogWindowManager）
▼ NAPI：liborcaslicerbridge.so（拓扑序 dlopen + 触摸/键盘/轴分发）
liborcaslicer_ohos_core.so（orcaslicer_ohos_main：gtk_init → wxEntryStart）
├── wxGTK 3.3.2 全家（base/net/xml/core/adv/aui/html/propgrid/richtext/stc/gl[EGL-OHOS]）
├── GTK3 栈（AirEDA gtk-stack，GDK OHOS 后端 + dialog subwindow ops）
└── Boost 1.85 / TBB / OCCT 7.8.1 / Python 3.11.9 / OpenVDB / CGAL / OpenCV 闭包
主要目录如下：
text
AirSlicer/
├── AppScope/app.json5 # com.airslicer.app、版本
├── PORTING.md # 移植档案：选型、补丁登记、风险与逐轮记录
├── native/scripts/ # env.sh、build_boost/wx/orca、deploy_orca、relink_full_core
└── entry/src/main/
├── module.json5 # sendData/viewData skills、READ_PASTEBOARD
├── ets/
│ ├── pages/NativeHost.ets # XComponent 宿主、静态菜单、V2 状态管理
│ ├── pages/DialogPage.ets # 对话框子窗口页（标题条拖拽/回写）
│ ├── components/ImeBridge.ets # 输入法桥
│ ├── managers/ImmersiveManager.ets # 沉浸式与自由多窗路由
│ └── utils/ # DialogWindowManager、FileManager、ShareManager
└── cpp/
└── napi_init.cpp # 薄 NAPI 桥：事件分发与通道
▍四、核心适配过程
### 1. 复用优先的依赖矩阵
工程把依赖分成三类处理：现成复用（AirEDA 的 GTK3 OHOS 栈、AirCad 的 OCCT 7.8.1 与 Python 3.11.9、AirRaw 的 libcurl）；源码自编（Boost 1.85 全 13 组件、OpenSSL 1.1.1w、TBB、CGAL 5.6.3、OpenVDB 全套、OpenCV 4.6 最小集、wxWidgets 3.3.2 Orca fork）；上游随构（imgui、libnest2d、clipper2 等树内依赖）。wxWidgets 的交叉构建打出 W 系补丁：configure 的 X11 链接置空、glegl 实现 OHOS GL canvas、filedlg/dirdlg 拦截改系统选择器、wxFrame 菜单栏隐藏。这套矩阵让约三十个第三方依赖在可控成本下进入闭包，构建链脚本（native/scripts/ 下 build_boost 到 deploy_orca 九步）按序可复现。
### 2. 3D 视口的 GLES 读回合成
鸿蒙侧没有窗口系统 GL 表面，工程利用 Orca 自带的 SLIC3R_OPENGL_ES 全量 GLES 路径：wxGLCanvasEGL 在 OnRealized 时建立 pbuffer，SwapBuffers 改为 glReadPixels 读回像素，GTK draw 回调里经 cairo ARGB32 上屏，含垂直翻转与 BGRA/GL_RGBA 通道探测。O 系补丁补齐 ES 上下文版本（EGL_CONTEXT_CLIENT_VERSION=3）、全局 SLIC3R_OPENGL_ES 宏定义，并修复了 libvgcode 的 ES 分支烂尾（Prusa SPE-2411 的 Vec3→Vec4 未同步、RGB32F 纹理在 GLES3 不存在等），冷启动 GLSL 报错弹窗在双机实证消失。渲染链早期还经历了七层破局：ES3 上下文强制、HasWindow 的 OHOS 语义、36 件 ES shader 资产自动转换、675 个桌面 GL 桩符号生成，最终 Maleoon GPU 真渲染打通。
### 3. 文件通道：选择器桥与分享接收
原生 GTK 文件对话框无桌面环境可用，W4/W5 补丁把 wxFileDialog 与 wxDirDialog 的 ShowModal 拦截，经 NAPI 转发到系统 DocumentViewPicker，支持 open/save/dir 三模式、后缀过滤、URI 到沙箱的 staging 中转与保存回拷同步守护。分享接收声明了 sendData/viewData 两个 skill 入口，want 带入文件经 fd 嗅探或 URI 中转进入 pendingOpen，配合 Ctrl+I 自动应答；碰一碰通过 harmonyShare dataReceive 注册。导入链经历九轮闭环：壳层链路先验证 100% 走通，再由源码定位出 native 侧 GetPaths 空数组静默早退的真正根因（见难点一），最终导入、落板、可重复得到实证。
### 4. 输入双模与触控补偿
触摸与鼠标双模分流：合成触摸源（鼠标/触控板）只取 MOVE 转光标，手指走全通道；OH_NativeXComponent 局部坐标与 GDK root 原点间的 +8.4px 固定残差用九连击像素测量定案并补偿。捏合缩放实现三源：滚轮轴、手指双指状态机（第二指落下对首指补 CANCEL、log2 距离比累积阈值转滚轮步进）、触控板 pinch 轴。对话框场景另建拖拽转滚轮通道：对话框内触摸拖拽超过 24px 转为滚轮步进注入，解决 GTK scrolledwindow 不吃鼠标拖拽而平板无滚轮的死结，真机验证滚动可达列表末尾且无伪点击。
### 5. 汉化、暗黑与布局治理
汉化走三通道：conf 的 app 节 language=zh_CN（真通道，此前顶层注入被忽略是首败根因）、dlopen 前置的 LANGUAGE/LANG 环境变量、rawfile 自带的 OrcaSlicer.zh_CN.mo 与 wxstd.mo。暗黑模式由壳层 setColorMode 钉死、conf dark_color_mode 每代启动幂等纠正。布局治理则是一组持久战：ui_scale 只放大字体而 em_unit 不随动导致固定行高裁切，工程以页签字号降档、行高分档上调、TabCtrl 间距收缩三处落补丁，DPI 2.5 档三处裁切全部关闭。
▍五、适配中遇到的几个难点
### 难点1：导入落板"轮盘"的九轮闭环
分享导入的文件应答送达后模型却不上板，早期表现为时好时坏，被称作"轮盘"。壳层先排除自身：knockFile 到 pendingOpen 到 W4 拦截到自动应答全链探针实证无损。破案最终落在 W4b：wx 文件对话框拦截态只回填了 GetPath 单数版本，而 Orca 的导入路径走 GetPaths 复数版本——无 widget 的 GTK chooser 在拦截态返回空数组，Plater::add_file 第一行的 empty 检查静默早退，先于任何日志，与"零报错零加载"完全吻合。补齐 GetPaths/GetFilenames/GetDirectory 三函数回填后随 wx 全量重建生效，STL 对象信息（20x20x20mm、12 三角形、零错误）逐字实证。这轮的教训是：静默失败必须下探到上游源码的早退分支，壳层探针齐全也只能证明自己无辜。
### 难点2：GL 视口错位的部署链无声降级
某轮构建后 3D 视口整体偏移约 500px，场景左半幅被截取。排查链覆盖了缩放、最大化、布局钳制后，GLSize 探针锁定单位量纲：Orca 在 ENABLE_RETINA_GL 下按 retina 因子取景，场景渲进了逻辑尺寸一半的 pbuffer。根因不在代码而在部署脚本：deploy_orca.sh 从 AirPhoto 构建树拷贝定制 libgdk，该树被删后静默回落到旧版本（scale 恒 2），单位翻面回归。修复三件套为后端权威源加回 GDK_OHOS_SCALE 读取、gtk3 全量重编、wx 增量重编对齐换算。这个案例的教训被写进档案：构建产物的静默降级比代码缺陷更难查，env 脚本失效要连接到症状面。
### 难点3：em_unit 膨胀挤窄 3D 画布
侧栏参数面板莫名膨胀到 585 DIP（基线 215），3D 画布被挤压。定位发现侧栏 AUI 面板的 BestSize 按 39 乘 em_unit 计算，而 em_unit 取自 GetTextExtent("m") 减一，在 OHOS 上恒为 15，与 ui_scale 无关，字体渲染正常但 extents 疑似物理逻辑双计。仅封顶面板 BestSize 无效（内容最小宽链把面板推回），最终在 update_em_unit 处封顶 10 生效，画布恢复。这类问题展示了 wx 布局体系对字体量测的深依赖，一个单位的量测偏差会沿布局链放大成整栏位移。
### 难点4：滚动失效假象与坐标系误判
参数面板被报告"滚动失效"，三轮补丁（FitInside、SetMinSize、SetClientSize）均无效。全树转储揭露真相：所有页签内容实际高度都装得下 905 视口，"内容超出视口底"是把 1381 逻辑像素当物理屏底的误判（窗口顶部还有 219 物理像素的状态栏偏移），y 大于 1600 的区域像素一致属帧缓存残影。破案后工程保留一个防御性安全网（换页后取后代真实底边、超视口时恢复滚动范围）应对专家模式等长内容场景，并把六类诊断探针全部清零、三库干净重编后交付。这个难点说明视觉表象必须先过坐标系审计，再动布局补刀。
### 难点5：上游确定性崩溃与对话框治理
全新安装后点击打印机下拉空白行必现 SIGSEGV。崩溃栈收敛到上游 on_select_preset 的确定性缺陷：get_similar_printer_preset 返回 nullptr 时弹出空 MessageDialog 提示，上游漏写 return，对话框栈析构后继续解引用空指针。补丁补上 return 并把空标题改为可识别文案，九次以上触发态复测零崩溃。对话框体系本身也经历系统治理：无 WM 环境下的多实例弹窗走 GDK 子窗口模式，标题条拖拽实现双通道（Touch 同步 startMoving 加 PanGesture 兜底）、拖拽回写 GTK 记账防隐形矩形死区、用户手动搬移后 tick 越界让渡主权，避免应用与用户"抢窗口"。
▍六、编译、安装与启动
Native 侧按 native/scripts/ 的固定顺序构建：env.sh 载入交叉环境（内置 PATH 前置 /usr/bin 防 diff 劫持、ohos-ld shim、elf_edit 原位编辑等工具坑对策），依次执行 build_boost、build_ssl_gmp_mpfr、build_small_deps、build_big_cmake_deps、build_openvdb、build_wx、build_orca，最后 deploy_orca.sh 收集闭包、NEEDED 去版本号并部署 rawfile 资源。ArkTS 与 HAP 打包使用标准 hvigorw 流程：
bash
export JAVA_HOME=/Applications/DevEco-Studio.app/Contents/jbr/Contents/Home
export DEVECO_SDK_HOME=/Applications/DevEco-Studio.app/Contents/sdk
hvigorw --mode module -p module=entry assembleHap --no-daemon
签名产物位于：
text
entry/build/default/outputs/default/entry-default-signed.hap
连接设备后安装并启动：
bash
hdc install -r entry/build/default/outputs/default/entry-default-signed.hap
hdc shell aa start -a EntryAbility -b com.airslicer.app
仅改动 ArkTS 或 napi 桥时，可跳过 native 链直接 hvigor 构建；档案记载的部署循环为 deploy_orca.sh 后接 devecocli build 与 devecocli run。2026-09-06 的 native 全链重建（新 wx 与新 core）后，冷启动约 12 秒进入完整深色中文主界面，导入、落板、页签巡检均有截图留痕。
▍七、当前功能边界
当前鸿蒙版已覆盖的能力（S1 到 S14 审计表的通过项）：
- 冷启动完整主界面：深色全中文、参数面板全量、3D 视口平台网格与坐标轴渲染、TabKick 自动激活 Plater 页；
- ArkTS 菜单栏与快捷键命令链（Ctrl+N/O/I/S/R/G/J/F/P 与 Shift 组合，对照上游 CHAR_HOOK 表）；
- 系统文件选择器三模式（打开/保存/目录）与后缀过滤、URI staging 回拷、文件夹授权与镜像同步守护；
- 分享与碰一碰接收、导入落板可重复（STL 对象信息逐字实证）、BBL 预设 59 机型加载；
- 触控与鼠标双模、双指捏合三源缩放、对话框拖拽滚动通道、+8.4px 坐标补偿；
- 全面汉化三通道、暗黑模式钉死与重启保持、剪贴板入向（权限动态申请与事件驱动）。
尚未覆盖或登记为缺口的能力（均有档案依据）：手写笔压感与倾角（NDK 无 PEN 源类型，待 native 重评估）；光标样式跟随（libgdk-3 无变化钩子）；剪贴板出向（后端仅暴露入向符号）；切片与保存工程的真手指端到端（通道就绪，自动化受注入工具限制待人工验证）；Monitor 设备监控页签（无网络通道，已裁剪）；自由窗下的队列子窗重显残影与恢复对话框打断首绘两项观感缺陷；短拖死区约 48px 的手势启动损耗。
因此，当前版本更准确的定位是"OrcaSlicer 鸿蒙原生移植的三设备验证版"：主界面、导入、预设与输入主链路在 MatePad 11.5、MatePad Mini 与 MateBook Pro 上实证，输出环节与少数外设通道如实登记为待验与缺口。
▍八、总结
AirSlicer 是 Air 系列里依赖最重、桌面耦合最深的一例：wxWidgets 界面体系、GLES 读回渲染、GTK 栈对话框、闭包级依赖矩阵全部要在无 WM 环境里重新落位。工程的价值不在单点突破，而在方法论的可复现：S1 到 S14 标准审计把"完成"定义成可检查项，补丁登记表让每个 W/O/A 系改动可回溯，逐轮档案把每个"复现不了"的现象收敛成根因链。导入轮盘与视口错位两个案例分别示范了源码早退分支取证与部署链静默降级排查，都是可迁移的破案范式。
后续工作的重心沿着档案中的挂账展开：切片与保存的真手指端到端验收、手写笔通道在 native 重建后的重评估、子窗残影与恢复对话框两项观感治理、以及短拖死区的校准。每一步延续同一纪律：以真机行为与截图留痕为验收依据，缺口不宣称完成，边界随重建与验证动态更新。
楼主
8 天前