Code__Blocks 鸿蒙 PC 适配全记录：从 wxWidgets 桌面 IDE 到沙箱内可运行的 C 开发环境

忆凡_

18人浏览 · 2026-09-13 16:05:45

忆凡_ · 2026-09-13 16:05:45 发布

欢迎加入开源鸿蒙 PC 社区：https://harmonypc.csdn.net/

欢迎在 PC 社区平台申请新建项目：https://atomgit.com/OpenHarmonyPCDeveloper

适配开源地址：https://atomgit.com/OpenHarmonyPCDeveloper/ohos_codeblocks

环境搭建文章：https://blog.csdn.net/weixin_52908342/article/details/161343743

一、为什么要适配 Code::Blocks

Code::Blocks 是一款历史悠久的开源 C/C++ 集成开发环境。它启动快、工程模型清晰，对编译器和调试器保持相对松散的耦合，在教学、算法练习、嵌入式开发以及轻量工程维护中仍有稳定的使用群体。对于习惯了“工程树、代码编辑器、构建日志”三栏布局的开发者来说，Code::Blocks 也代表了一套成熟且低门槛的桌面开发工作流。

HarmonyOS PC 的应用生态正在向生产力场景扩展。适配 Code::Blocks 的价值，不只是让一套经典界面出现在鸿蒙桌面上，而是验证两个更实际的问题：传统 C++ 桌面软件怎样跨过 GUI 框架缺失的障碍；在没有系统编译器、不能任意执行新生成机器码的应用沙箱中，怎样保留“编辑—构建—运行—查看结果”这条 IDE 核心链路。

本次适配以上游 Code::Blocks 25.03 为基础，鸿蒙版本号为 25.03-ohos-lite，应用包名为 org.codeblocks.codeblocks，面向 2in1 与 tablet 设备，Native 架构为 arm64-v8a。仓库继续保留上游 wxWidgets 源码与桌面端构建系统，鸿蒙工程则作为独立目录维护，避免平台适配反向破坏原项目。

二、先确定适配边界：不能把 wxWidgets 工程直接塞进 HAP

上游 Code::Blocks 并不是一个单纯的编辑器。它由 SDK、wxAUI 窗口系统、工程模型和大量动态插件共同组成，编译器、调试器、代码补全、工程导入、wxSmith 等能力也长期围绕 wxWidgets 演进。当前 wxWidgets 没有可直接使用的 OpenHarmony 后端，如果从窗口系统开始移植，不仅工作量巨大，还要持续维护新的平台端口和插件 ABI。

因此，鸿蒙版本没有声称完整搬入上游全部模块，而是围绕日常使用频率最高的闭环重新划分能力：

层次	上游实现	鸿蒙侧处理方式
应用入口	桌面进程与 wxWidgets 事件循环	Stage 模型 `EntryAbility` + XComponent 宿主
桌面界面	wxWidgets / wxAUI	Qt 5 Widgets 重建三栏 IDE 外壳
工程模型	`.cbp`、`.workspace`	保留 XML 格式解析与写回，兼容常用工程结构
编辑能力	Scintilla 与插件扩展	轻量编辑器、行号、语法高亮、缩进、查找与词汇补全
构建运行	外部 GCC/Clang 与进程工具链	内置 picoc，纯解释执行 C 程序
调试与插件	GDB/CDB、动态插件	当前版本不移植，按鸿蒙安全边界重新评估

这一路线的核心判断是：先让一个 C 工程能够被创建、编辑、检查并真实运行，再讨论平台暂时无法承载的完整编译器、调试器和插件生态。lite 表示能力边界透明、依赖收敛，并不把未迁移模块包装成已经支持。

三、鸿蒙版本的整体架构

鸿蒙工程位于仓库根目录的 harmony_pc/。ArkTS 只承担 Ability 生命周期与窗口宿主，NODE 类型 XComponent 承载 Qt 画面；Qt for OpenHarmony 的 QPA 插件启动 libentry.so，IDE 界面、工程管理和解释执行逻辑集中在 Native 层。

EntryAbility
    └── Index.ets / XComponent
          └── Qt for OpenHarmony QPA
                └── libentry.so
                      ├── Code::Blocks 风格三栏桌面外壳
                      ├── .cbp / .workspace 工程模型
                      ├── C/C++ 代码编辑与辅助功能
                      ├── picoc 构建检查与 C 解释执行
                      └── QSettings 会话和编辑器设置持久化

主要目录如下：

ohos_codeblocks/
├── src/                                  # 上游 Code::Blocks 完整源码
├── configure.ac / Makefile.am            # 上游桌面端构建入口
├── README.OpenHarmony_CN.md              # 鸿蒙适配说明
└── harmony_pc/
    ├── AppScope/app.json5                # 应用包名、版本和图标
    ├── build-profile.json5               # SDK、产品和签名配置
    ├── audit_so.sh                       # Native 与 HAP 产物审计
    ├── qtforharmony_sdk/                 # Qt for OpenHarmony SDK
    └── entry/src/main/
        ├── ets/                           # Ability 与 XComponent 宿主
        ├── module.json5                  # 设备类型和模块声明
        └── cpp/
            ├── CMakeLists.txt            # Native 构建入口
            ├── codeblocks_harmony.cpp    # IDE 主界面与业务流程
            ├── resources.qrc / res/      # 上游图标资源
            └── picoc/                    # 内置 C 解释器及鸿蒙补丁

这种分层刻意保持 ArkTS 宿主轻量：窗口生命周期交给系统，传统桌面交互留在 Qt 层，C 解释器则作为库被 IDE 调度。页面状态不需要在 ArkTS 和 C++ 之间反复镜像，工程文件、编辑器和运行任务也能够共享同一套 Native 数据模型。

四、把 IDE 的核心工作流真正跑起来

以下五张截图均来自本项目签名 HAP 在 HarmonyOS PC 真机上的实际运行画面。测试设备为 HUAWEI MateBook Pro（HAD-W32，2in1），系统版本为 6.1.0.117，截图分辨率为 3120×2080。本次记录重新安装并启动了 arm64-v8a 产物，再依次完成示例工程加载、构建运行、符号与待办扫描以及标准输入测试。

1. 先恢复熟悉的桌面 IDE 信息架构

启动页保留 Code::Blocks 的经典桌面组织方式：左侧是工程与符号管理器，中间是多标签编辑区，底部统一承载构建日志、构建信息、程序输出、搜索结果和待办事项。菜单和工具栏继续沿用上游使用习惯，F9 用于构建并运行，Ctrl+F9 只执行构建检查。

在这里插入图片描述

窗口并非静态首页。Qt 界面由 QPA 插件挂载到 XComponent，Native 入口完成后会写入 CodeBlocksQt hilog 标签；窗口几何、最近工程和编辑器设置则由 QSettings 保存。工程或文件集合发生变化时采用防抖落盘，避免系统直接回收应用时无法执行传统桌面的 closeEvent，导致会话丢失。

2. 工程模型与编辑器要能形成真实上下文

示例工程 HelloOHOS 由 main.c、fib.c 和 fib.h 组成，验证的不是单文件演示，而是源文件、头文件和本地包含关系。工程树读取 .cbp 中的标题与 <Unit filename>，保存时写回可被桌面版识别的最小工程结构；.workspace 也可以作为多工程入口打开。

在这里插入图片描述

编辑器基于 QPlainTextEdit 扩展，提供行号、当前行高亮、修改状态、C/C++ 关键字与预处理语法高亮、跨行注释、自动缩进、块缩进和 Ctrl+/ 注释切换。补全采用 C 关键字与当前文档标识符组合，不依赖沙箱中不存在的 clangd 进程。文件保存通过 QSaveFile 原子写入；读取时优先使用 UTF-8，遇到非法序列再按 GB18030 解码，以兼容常见的 Windows 中文源码。

3. 构建与运行不能只停留在按钮可点击

HarmonyOS 应用沙箱没有可供普通应用直接调用的 GCC/Clang 工具链，同时 W^X 策略也不允许应用随意生成并执行机器码。本项目将 picoc 作为内置库：构建阶段解析工程中的 C 单元并输出文件、行号和错误信息；运行阶段解析后调用 main()，通过重定向管道把输出实时送入 IDE 的“程序输出”面板。

在这里插入图片描述

截图中的 fib(1) 到 fib(10) 来自真机上的实际解释执行。任务运行在工作线程，界面不会因解析或递归计算而阻塞；结束状态通过共享结果和 EOF 时序统一收口，确保退出码不会抢在最后几行输出之前出现。构建错误会进入结构化表格，双击即可回到对应文件和行。

4. 符号与 TODO 需要和工程导航连起来

精简版没有在沙箱中额外启动 LSP 服务，而是对当前工程与已打开文件执行轻量扫描。符号浏览识别函数、结构体和宏；待办列表识别 TODO、FIXME、BUG、HACK，并记录文件和行号。双击条目可以直接切换编辑器并定位到源代码。

在这里插入图片描述

图中左侧已经从 fib.h 识别出 FIB_H 宏，底部则定位到 main.c 第 10 行的 TODO。它们与工程树、编辑器使用相同的绝对路径和行号模型，因此不只是独立的扫描结果展示。全工程查找、构建错误定位和代码统计也复用这一文件范围。

5. 没有终端，也要解决标准输入

普通 HAP 没有交互式 stdin 终端，如果直接沿用 picoc 的标准输入，scanf、getchar 和 gets 会拿不到数据，甚至可能阻塞运行线程。鸿蒙版在“构建”菜单中提供“程序输入（stdin）”对话框，用户在运行前准备输入内容；宿主将其写入临时输入流，再由 picoc 的输入重定向钩子读取。

在这里插入图片描述

这不是对输出文本的模拟：示例代码执行 scanf("%d", &x)，真机结果显示输入值 7 和计算结果 49。对死循环任务，picoc 语句解析路径还加入了中止检查，点击“停止运行”后在下一条语句处安全退出，构建信息会报告用户中止。受平台交互模型限制，当前输入仍需在运行前一次性准备，不能像终端那样边运行边逐次输入。

五、适配过程中最棘手的几个问题

难点一：wxWidgets 与插件体系无法做机械式替换

Code::Blocks 的窗口、命令、工程服务和插件管理长期相互协作。若只把控件逐一替换为 Qt，最终会留下大量依赖 wxWidgets 事件、动态插件和桌面进程模型的断点。适配时先用用户流程确定边界，再用 Qt 重建工程树、编辑器和日志面板，将构建运行、符号、TODO、搜索等高频能力以内建模块提供。这样牺牲了插件的即时扩展性，却换来了可审计、可打包的依赖集合。

难点二：IDE 的核心能力受到沙箱执行策略约束

桌面 IDE 通常只负责组织命令，真正的编译和运行交给外部工具链；鸿蒙应用沙箱中既没有系统 GCC/Clang，也不能把运行期生成的本地代码直接作为普通程序执行。选择 picoc 是工程约束下的折中：它覆盖 C90 常用子集，支持多文件、本地头文件、递归和常用库函数，又不会生成机器码。相应地，当前版本明确不支持 C++ 真编译、GDB 调试和完整编译器参数体系。

难点三：picoc 在 musl 与 IDE 输出模型下需要专门改造

直接编入 picoc 会遇到 musl 下 FILE 类型差异、部分函数缺失和 readline 不可用等问题。项目对这些平台差异进行了最小修补，同时增加 stdout、stdin 和中止状态钩子。stdout 进入 IDE 管道，stdin 读取运行前准备的数据，中止请求在语句边界检查；三者共同解决“能执行但无法交互、无法观察、无法停止”的问题。

难点四：真机文件目录与桌面开发机的假设不同

QStandardPaths::DocumentsLocation 在真机上可能指向公共 Documents 目录。创建目录成功不代表随后一定拥有文件写权限，初版示例工程因此会在真正写入时失败。当前实现会执行实际写入探测，不可写时回退到应用沙箱的 AppDataLocation。本次真机示例工程路径落在 /data/storage/el2/base/files/CodeBlocksProjects/，工程创建、编辑和会话恢复均可持续使用。

难点五：Qt 对话框焦点与鸿蒙生命周期必须真机验证

非模态查找对话框在 OHOS QPA 下曾无法获得键盘输入焦点，改为与桌面使用习惯一致的模态执行后才恢复输入。另一个问题是系统回收或 force-stop 不保证触发窗口关闭事件，所以仅在 closeEvent 保存会话并不可靠。最终将会话保存前移到工程和文件状态变化时，窗口关闭只作为补充。此类问题无法通过“编译成功、首页可见”发现，必须在真机上连续操作才能暴露。

六、构建、安装与启动

首次构建建议使用 DevEco Studio 打开仓库中的 harmony_pc/，等待工程同步完成，确认 entry/build-profile.json5 中的 Qt SDK 路径有效，再为包名 org.codeblocks.codeblocks 配置与当前设备匹配的调试签名。工程配置的 compatible SDK 为 5.0.5(17)，Native 编译器为 BiSheng，ABI 为 arm64-v8a。

命令行构建示例如下：

cd harmony_pc
export DEVECO_SDK_HOME=/Applications/DevEco-Studio.app/Contents/sdk
export JAVA_HOME=/Applications/DevEco-Studio.app/Contents/jbr/Contents/Home
export PATH="/Applications/DevEco-Studio.app/Contents/tools/node/bin:$JAVA_HOME/bin:$PATH"

/Applications/DevEco-Studio.app/Contents/tools/hvigor/bin/hvigorw assembleHap \
  --mode module -p product=default -p buildMode=debug --no-daemon

bash audit_so.sh

audit_so.sh 会检查 libentry.so 是否为 AArch64 ELF、Qt 依赖是否完整，以及 HAP 内是否包含 qopenharmony QPA 插件和运行所需 Qt 库。签名产物生成后，可通过以下命令安装和启动：

hdc list targets
hdc install -r entry/build/default/outputs/default/entry-default-signed.hap
hdc shell aa start -b org.codeblocks.codeblocks -a EntryAbility

本次文档验证使用的签名 HAP 约 22 MB。安装命令返回成功后，真机依次完成启动页、三文件示例工程、F9 构建运行、符号与 TODO 扫描、stdin 输入和结果回显，五张截图均由 snapshot_display 从当前设备画面直接取得。

七、当前功能边界

当前版本已经覆盖轻量 C 开发场景的主线能力：

.cbp 工程新建、打开、保存，以及 .workspace 工作区入口；
多标签代码编辑、行号、C/C++ 语法高亮、缩进、注释切换与词汇补全；
picoc 多文件 C 构建检查、错误定位、解释运行与实时输出；
运行前标准输入、语句级中止和退出状态显示；
文件内查找替换、全工程搜索、符号浏览、TODO 扫描和代码统计；
最近工程、最近文件、会话恢复、深浅主题和编辑器设置持久化；
HarmonyOS PC 窗口宿主、签名 HAP 安装以及 arm64-v8a Native 产物审计。

尚未纳入当前版本的能力包括 GCC/Clang/MSVC 真编译器链、C++ 构建运行、GDB/CDB 图形化调试、wxSmith 设计器、上游二进制插件体系、clangd/LSP、版本控制终端，以及运行期间逐次交互的 stdin。符号浏览是轻量规则扫描，复杂宏和函数指针声明可能漏识别；picoc 主要覆盖 C90 常用子集，部分 C99/C11 特性不适用。

因此，更准确的产品定位是“Code::Blocks HarmonyOS PC 轻量 C 开发版”：它保留了经典 IDE 的工程组织和编辑体验，并在真机沙箱内打通了可观察、可输入、可中止的 C 解释执行闭环，但不等同于桌面版完整工具链和插件生态的逐项复制。

八、总结

Code::Blocks 的鸿蒙适配表明，传统桌面开发工具迁移到 HarmonyOS PC，最难的部分通常不是重画窗口，而是识别平台不可直接继承的运行假设。wxWidgets 后端、外部编译器、动态插件、stdin 终端和进程调试在桌面系统上习以为常，进入应用沙箱后都需要重新设计边界。

本项目用 Stage 模型和 XComponent 接住鸿蒙应用生命周期，通过 Qt for OpenHarmony 重建桌面 IDE 外壳，再用 picoc 补上沙箱内的 C 构建与运行能力。工程文件兼容、编辑辅助、标准输入、输出排序、中止机制和会话恢复则保证这条链路不仅能演示，而且能够被连续使用。

对于其他依赖传统 GUI 框架和外部工具链的开发者工具，这次实践提供了一条可复用的顺序：先确定最有价值的用户闭环，再替换平台外壳；随后把外部进程能力改造成沙箱内可控的库能力，最后以真机上的输入、输出、停止和恢复结果验证适配是否真正完成。