A
Air官方
很多 KDE 出品的实用工具不只用 Qt，还依赖 KF6（KDE Frameworks）的一串框架库：配色与图标主题、配置读写、窗口系统extras、文档框架等。把这类应用带上鸿蒙，光有 Qt 栈不够，要评估整条 KF6 依赖链。
▍KF6 依赖链的形态
一个典型 KDE 应用可能拉进 KWidgetsAddons、KConfig、KIconThemes、KColorScheme 等十几二十个 KF6 模块，每个又是独立 CMake 工程。好消息是绝大多数 KF6 模块是纯 Qt 库，不碰系统底层；坏消息是总有几个模块会去探测 dbus、桌面服务、XDG 目录结构，这些在鸿蒙沙箱里要么不存在要么路径不同。
▍移植策略
第一层：把应用实际用到的 KF6 模块列全（CMake 报错驱动逐个补即可），纯 Qt 模块直接交叉编译。第二层：对碰桌面假设的模块做环境侧兜底——XDG 路径映射到应用沙箱目录，dbus 依赖用桩库满足链接、运行时短路，主题引擎指向随包携带的图标与配色资源。第三层：窗口层差异交给 ohos QPA，KWindowSystem 这类查询接口在无 WM 环境返回合理默认值。
▍取舍提示
KF6 全家桶很大，能不用就不用：如果应用只是用 KF6 的某个按钮控件或对话框，评估用 Qt 原生件替换的成本可能更低。反过来，深度绑定 KF6 配置体系的应用就老老实实搬模块，替换成本会失控。
▍Air 系列的实践
Air 工作区设有专门的 kf6 框架目录，Qt 共享栈命名为 qt-kde-stack，命名本身就说明了 KDE 系工程在这条线上的位置。 KDE 系工具的移植经验与 Qt 主线互相反哺：QPA 的触摸与窗口修复，KF6 工程直接受益。
▍建议
立项前先跑一遍应用的依赖清单工具，把 KF6 模块数、含桌面假设的模块数数出来，超过十个且半数碰桌面，就要认真评估换成无头核心加 ArkUI 界面的双引擎路线。
有疑问欢迎在本板块直接发帖，我们会逐条回复。
▍KF6 依赖链的形态
一个典型 KDE 应用可能拉进 KWidgetsAddons、KConfig、KIconThemes、KColorScheme 等十几二十个 KF6 模块，每个又是独立 CMake 工程。好消息是绝大多数 KF6 模块是纯 Qt 库，不碰系统底层；坏消息是总有几个模块会去探测 dbus、桌面服务、XDG 目录结构，这些在鸿蒙沙箱里要么不存在要么路径不同。
▍移植策略
第一层：把应用实际用到的 KF6 模块列全（CMake 报错驱动逐个补即可），纯 Qt 模块直接交叉编译。第二层：对碰桌面假设的模块做环境侧兜底——XDG 路径映射到应用沙箱目录，dbus 依赖用桩库满足链接、运行时短路，主题引擎指向随包携带的图标与配色资源。第三层：窗口层差异交给 ohos QPA，KWindowSystem 这类查询接口在无 WM 环境返回合理默认值。
▍取舍提示
KF6 全家桶很大，能不用就不用：如果应用只是用 KF6 的某个按钮控件或对话框，评估用 Qt 原生件替换的成本可能更低。反过来，深度绑定 KF6 配置体系的应用就老老实实搬模块，替换成本会失控。
▍Air 系列的实践
Air 工作区设有专门的 kf6 框架目录，Qt 共享栈命名为 qt-kde-stack，命名本身就说明了 KDE 系工程在这条线上的位置。 KDE 系工具的移植经验与 Qt 主线互相反哺：QPA 的触摸与窗口修复，KF6 工程直接受益。
▍建议
立项前先跑一遍应用的依赖清单工具，把 KF6 模块数、含桌面假设的模块数数出来，超过十个且半数碰桌面，就要认真评估换成无头核心加 ArkUI 界面的双引擎路线。
有疑问欢迎在本板块直接发帖，我们会逐条回复。
楼主
7 天前