编辑的话请把自己的名字加到作者名单里

DDE v23 RC 即将随 deepin v23 RC 发布（你阅读到这个文章的时候可能已经发布了）。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。 {.note}

概览

相比 beta2 -> beta3 而言，原本处于技术预览状态的 dde-shell 项目现已开始逐步取代部分旧的 DDE 组件。DDE 此次 beta3 -> RC 的更新中，dde-shell 取代了 dde-dock 项目，dde-launchpad 也开始转为使用 dde-shell 的对应插件版本。同时，由于对 Qt6 与 DTK6 使用的增加，我们也对 DTK 进行了大量的问题修复，这些修复也被对应的组件（dde-launchpad 与 dde-shell）依赖。

由于这些项目的版本间互相影响，我们建议移植人员参照 deepin v23 RC 所使用的包版本进行打包，下面会对主要的部分进行详细说明。

需要注意的是，由于此文章编写时间早于版本发布时间，故最终版本镜像中使用的版本可能高于下面列出的版本。我们尽可能确保此文章的准确性，但若您需要获取 ISO 镜像中使用的确切软件版本列表，请挂载 ISO 后参阅 LIVE/FILESYS0.MAN 路径对应的文件的内容。

主要组件

DTK 与 DTK6

DTK 是 DDE 组件与应用的基础依赖，适用于 RC 的版本参照如下：

本次 DTK 版本号以及相对应的平台插件等版本号均已对齐，可直接参照打包。

关于 qt5platform-plugins，现有的 dwayland 插件可能对非 DDE 环境（例如 KDE）的 wayland 用户存在影响，可参照 linuxdeepin/developer-center#7217 打对应的 patch 规避影响。

dtk6 曾对 Qt 6.2, Qt 6.4 和 Qt 6.6 均进行过适配，我们目前的研发与测试主要使用 Qt 6.6 版本。对于 Qt 6.7 我们暂未进行主动支持，对于 Qt 6.7 的相关处理请先参照 Arch Linux 目前使用的 qt-6.7.patch。

目前，使用 dtk6 的正式组件有 dde-application-manager，dde-launchpad 与 dde-shell，技术预览组件有 treeland。

DDE 主要组件

下面仅涉及变化较大或影响较广的组件。其余未涉及的组件可正常参照最新 tag 进行打包与移植。

下面涉及到的组件的版本参照如下：

dde-application-manager

本次此组件并不存在如 beta2 -> beta3 阶段时的巨大变化，但由于此组件仍为诸多组件的核心依赖，并且此组件也因其它组件需要而增加了一些新的接口，故建议总是使用最新版本。

dde-shell

dde-shell 旨在将 DDE 桌面环境插件化与模块化，降低开发难度，使各个组件的替换变得更加容易，并且提供更好的桌面环境集成支持。RC 阶段，dde-shell 已经可以满足原计划的部分目标。现 DDE 环境下，dde-shell 已取代 dde-dock 来负责管理整个 dock 区域，并且 dde-launchpad 也提供了（且默认使用）对应的 dde-shell 插件，用以展示启动器相关的界面。

尽管 dde-shell 也包含了一份通知中心插件，但这个插件并不会在 RC 中被启用。

出于初期快速开发目的，dde-shell 本身内附了诸多其它项目的托盘插件代码以及一些第三方库，这部分的代码会在后续版本迭代中逐渐被调整或移除。对于这些代码，可在移植过程中先行酌情调整或移除。项目内附的 networkmanager-qt 依赖也会在后续移除，转而使用系统版本。由于 RC 版本不会涵盖此变更，若有需要，请参见 linuxdeepin/dde-shell#286。

dde-launchpad

RC 版本中，dde-launchpad 不再支持 Qt 5 构建，也不再直接支持以独立进程的形式被最终用户使用（事实上仍然支持，但仅供开发调试场景下使用）而仅支持以 dde-shell 插件的形式被最终用户使用。因而，打包 dde-launchpad 现需要先打包 dde-shell，并确保用户最终使用的是 dde-shell。

dde-session

在之前的版本中，dde-session 提供的相关 systemd 服务依赖关系会导致进入 KDE 环境时也会拉起 DDE 相关的服务，最终由于拉起失败导致 KDE 环境也无法进入。在 RC 版本的 dde-session 中，此问题应当已被解决。

另外重申，我们已在 beta3 阶段放弃了对 deepin-kwin wayland 的支持，DDE 后续所有 wayland 相关的支持均由 treeland 提供。

技术预览组件

技术预览阶段的组件均可酌情决定是否打包。需要注意的是，这些组件并不一定在 RC 阶段存在改善。

treeland / ddm

treeland 目前是技术预览阶段的项目，兼顾 Wayland 窗口合成器和显示管理功能。treeland 除需要 dtk6declarative 外，还依赖新项目包括 waylib 和 qwlroots。需要使用 Qt 版本 >= 6.6.0， wlroots 版本 >= 0.17.0 编译 qwlroots/waylib。

ddm 的仓库也在 RC 阶段进行了拆分，现在 ddm 与 treeland 已是分别独立的两个仓库进行维护了。

deepin-im

treeland 目前是技术预览阶段的项目，提供了输入法的抽象层。目前，deepin-im 仅期望在 treeland 环境下使用。它会设置 QT_IM_MODULE 等环境变量的值来影响实际使用的输入法模块。

RC 版本中，并未涉及对 deepin-im 组件的改善。

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

• Matrix 群：#dde-port:deepin.org
• Telegram 群：https://t.me/ddeport

目前 dde-nixos 已经分叉，mian 分支进行 v23 的维护，目前主要更新了 dtk 和部分 deepin 开头的应用， dde 开头的核心应用移植暂未实现，dbus 接口不兼容，因此目前不可日常使用。

gomod 分支用于测试使用 buildGoModule 完成构建，仅验证可行性，实际使用还需要调整硬编码相关的 patch。

日常使用 DDE 需要切换 v20 分支，会优先使用已经提交到上游的应用：

   dde-nixos = {
      url = "github:linuxdeepin/dde-nixos/v20";
      inputs.nixpkgs.follows = "nixpkgs";
    };

在 v20 分支，dtk 使用 5.6.3 不再升级，deepin 应用会保持最新的 v20 版的最新版本（不会上 6.0.0），dde 应用冻结为 1 月份打包时测试可用的版本，一般不再升级：

既除了 deepin 应用，其他应用只有在 v23 移植完成后再更新。

目前 NixOS 23.05 — Feature Freeze & Release Blockers 已经开始，进度请关注： https://github.com/NixOS/nixpkgs/issues/224457#issuecomment-1501383113

向上游贡献的主要调整：

1. 调整 patch

在 dde-nixos 中，编写了 getPatchFrom， replaceAll 等函数帮助 patch 硬编码路径，但打包时为上游添加函数是难以接受的，因此所有的 patch 都需要使用 substituteInPlace 重写：

一个典型的例子是：https://github.com/NixOS/nixpkgs/pull/217806

2. 改善对交叉编译

所有 deepin 启用 strictDeps，调整了 nativeBuildInputs 和 buildInputs 不规范的地方，（使用 qmake 的除外，会造成 qtwebengine 找不到，且上游已经不太关心 qmake）

strictDeps 下无法传播 qtimageformats 问题 ，由 NickCao 解决

ps：可以使用 nix-build -A pkgsCross.riscv64.deepin.dtkcore 尝试交叉编译。目前 x86_64 和 aarch64 可正常编译。

obs 全称 Open Build Service，是一个开放的构建平台。相较于其他构建工具有以下优点：

• 支持跨平台构建（x86、arm64 等）
• 支持多种虚拟环境（kvm、lxc、chroot 等）
• 支持软件包构建（deb、rpm、pkg 等）
• 支持容器构建（flatpak、appimage、docker 等）
• 支持发型版镜像构建（debian、windows 等）

玲珑 是一种新型的独立包管理工具集，致力于治理 Linux 系统下传统软件包格式复杂、交叉的依赖关系导致的各种兼容性问题，以及过于松散的权限管控导致的安全风险。

本文介绍怎么给 obs 添加玲珑构建支持，供以参考实现你自己的 obs 构建服务。

deepin v23 beta 的发布在即，为了能够使相关的 bug 能够得以更快解决，并促进研发团队的协作变得更高效，我们（开源社区中心）决定在 deepin 员工内部举办小规模的 bug hunting 性质的比赛，并命名该比赛为“小浣熊杯修 bug 大赛”。而首届“小浣熊杯”也于昨天顺利落幕，那么就让我们一起了解一下这个比赛吧！

比赛介绍

如上所述，“小浣熊杯“的比赛大致内容即为在比赛时间内对已有缺陷进行修复。我们将所有参赛的员工划分为多个组，每个组除研发外也配备一个测试人员。在比赛时间周期内，研发从指定的缺陷看板中挑选自己”中意“的 BUG 进行修复，并在修复后将修复公布在相关群内，由 其他组 的测试人员进行测试。当修复被测试人员验证没有问题后，即可进行计分。最终，会以本组研发人员所修复的数量与测试人员所完成的测试数量相组合，并计算小组人均得分，最后以小组人均得分的高低决定最终排名。

小组得分的计算公示为：

小组得分 = (本组研发修复的缺陷数量 + 本组测试所验证的缺陷数量 / 3) / 小组总人数

比赛会在 https://github.com/linuxdeepin/.bug-game/ 中进行，每次比赛会创建一个看板来跟进整个比赛的实时情况，并创建一个对应的 issue 记录相关进展与结果。

另外，考虑到比赛过程中对缺陷的修复不需要经过其他研发人员的 code review ，因而可能存在实际的代码质量问题，故相关的 PR 均不要求在比赛结束前合入，相关提交仍需按照正常流程，经过有效 review 获得 approval 后合入。

首届状况介绍

首届比赛共划分了四个小队参赛，比赛时间从 3 月 7 日开始，为期两天。比赛过程与结果在 这个 Issue 中汇总，最终的缺陷修复情况也可以参见 这个看板。比赛过程中“修 bug”队一度领先，随后被”进击的小浣熊“队反超，最终经过了两天的”激烈比拼“后，本次比赛总计处理了 42 个 Issue，由”进击的小浣熊“队以 18.333 分的总积分获得人均积分第一夺冠。“修 bug”队紧随其后，“呆呆鹅” 与 “bug 收割小分队” 获得随后的名次。

比赛过程中，各个小组对已有 bug 的挑选与“占坑”以及测试人员对新提交修复的“抢单”是过程中最有趣的事情之一。快速挑选便于修复的 BUG 并进行有效的修复成为了获胜的关键之一，根据表象快速分析推测问题的能力，以及在陌生项目¹中快速尝试定位和修复问题的能力也变得至关重要。作为花絮，有的小组也在选择 BUG 的过程中连续发现自己所选择的缺陷实际早已在版本迭代中被修复，耗费了较多时间而造成了相对的失利，但这个过程也对现存 BUG 的有效性验证有很大的帮助²。

赛后，我们进行了比赛的颁奖，获胜队伍获得了比赛限定奖杯与荣誉证书，以及一个 deepin 主题背包。获奖队伍也进行了合影：

无论是否获奖，我们都感谢各个参赛队伍的积极参与，也希望各位能在后续的比赛中能够获得优异的成绩。

deepin 社区博客

deepin 社区公共博客平台。

用法说明

此博客平台使用了 HUGO 作为文章平台工具，进行博客文章的静态生成，并最终利用 GitHub Pages 呈现网页。故整个过程你只需按照 HUGO 的正常使用方式进行使用即可。

若未安装 HUGO，您可以从 HUGO 官方 GitHub 仓库的 Release 页面获取适用于您设备的 HUGO 版本，并放置其于 PATH 内以便调用。

安装就绪后，大致常用命令如下（在此源码仓库的根目录下执行）：

$ hugo server # 启动一个本地服务器，预览目前状态下的网站内容
$ hugo new posts/my-post.md # 创建一篇新文章，以便进行编辑
$ hugo server -D # 启用本地服务器，并且能够预览状态为草稿（`draft: true`）的文章
$ hugo -D # 生成静态页面（如果需要），生成的文件将位于 public 目录下

创建文章时，创建格式为 <分类>/<文件名>.<格式>，上面给出的例子中，分类为 posts，文件名为 my-post，格式为 md （markdown）。创建文章后，默认会使用 YAML front-matter 标记文章的一些元信息，请留意 draft 草稿状态的文章最终不会显示。

若要获取 HUGO，请参考官方文档给出的安装方式。

文章内容指导建议

向此博客平台投递文章需要经过相关人员的 review，合入后即投递完成。需要注意的是，向此处投递的文章必须是与 deepin 社区发展所相关的文章。对于与 deepin 开源社区贡献相关的个人感想或随笔等博客，可以考虑发布到 planet.deepin.org 聚合平台，此博客平台的文章也会出现 planet.deepin.org 之中。

在发布您的文章时，建议使用标签来标记您文章所相关的主题，以便读者更方便的查阅您的文章。例如 tags: ["持续集成"] 或 tags: ["指南文档", "CMake"]。另外也建议在文章的元信息中附带作者信息，例如 authors: ["张三"]（可为多人）。

改善此项目的样式风格

此项目使用了 geekblog 主题（基于 v0.5.3，有改动）。若你有任何建议，可以进行讨论并修改或提供更适合的主题。

编辑的话请把自己的名字加到作者名单里

DDE v23 beta3 即将随 deepin v23 beta 3 发布（你阅读到这个文章的时候可能已经发布了）。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。 {.note}

概览

DDE 此次 beta2 -> beta3 的更新中，dde-application-manager 进行了大规模重构；dde-launchpad 取代 dde-launcher 成为了新的启动器/开始菜单应用；新的技术预览项目 dde-shell 和 treeland 也随此次发布提供了初步版本，以及为了服务 dde-launcher 和 dde-shell，dtk 也开始提供 Qt 6 版本。

由于这些项目的版本间互相影响，我们建议移植人员参照 deepin v23 beta3 所使用的包版本进行打包（随后会把完整的版本参照列表贴到这里），下面会对主要的部分进行详细说明。

主要组件

DTK 与 DTK6

作为 DDE 组件与应用的基础依赖，DTK 现开始提供 Qt 6 支持。适用于 beta 3 的版本参照如下：

由于 dtkdeclarative 和 dtkgui 存在一些发布前的紧急修复，所以这两个组件存在版本号未对齐的情况。请直接参照上述表格的版本进行打包，以便确保 dtk 自身互相依赖的版本无误。

关于 qt5platform-plugins，现有的 dwayland 插件可能对非 DDE 环境（例如 KDE）的 wayland 用户存在影响，可参照 linuxdeepin/developer-center#7217 打对应的 patch 规避影响。

dtk6 曾对 Qt 6.2, Qt 6.4 和 Qt 6.6 均进行过适配，但我们目前的研发与测试主要使用 Qt 6.6 版本，故我们建议使用尽可能新的 Qt 6 版本。

目前，使用 dtk6 的正式组件有 dde-application-manager 以及 dde-launchpad，技术预览组件有 dde-shell, treeland。

dde-application-manager

dde-application-manager 自 1.1.0 版本起进行了完整重构（此次随 beta 3 发布的版本是 1.1.8），接口存在完全不兼容的变动。故原本依赖重构前 dde-application-manager 的应用程序和组件均需要进行更新。比较典型的组件为 dde-dock 与 dde-file-manager。

dde-launchpad

dde-launchpad 取代了 dde-launcher，原 dde-launcher 由于大量缺陷以及对旧 dde-application-manager 的强依赖，已不再可用。如果您的发行版在使用 dde-launcher，现在可以废弃 dde-launcher 并使用 dde-launchpad 替代了。

尽管在 deepin 中，dde-launchpad 使用的是 Qt 6 构建的版本，dde-launchpad 本身仍然提供了选项来控制使用 Qt 5 或是 Qt 6。我们建议在允许的情况下尽可能使用 Qt 6 而不是 Qt 5，以及无论 Qt 5 或是 Qt 6 支持，请都不要忘记安装 qt5/6integration 插件以及 qt5/6platform-plugins，否则 dde-launchpad 可能会缺失圆角与模糊效果。同样，强烈建议配合最新 DTK 版本构建来获得最佳显示效果。

另外，随 dde-launchpad 一并发布了 dde-application-wizard 项目。此项目是一个守护进程，提供对旧的 dde-application-manager 所提供的卸载服务接口的兼容支持，但可被移植到支持 packagekit 的发行版，故您可以考虑打包移植此组件。如果您的发行版不支持 packagekit，则可考虑暂时 patch dde-launchpad 来隐藏菜单中的卸载按钮，后续 dde-launchpad 会提供 DConfig 来便于发行版定制这些菜单项。

技术预览组件

技术预览阶段的组件均可酌情决定是否打包。

dde-shell

dde-shell 目前是技术预览阶段的项目。dde-shell 旨在将 DDE 桌面环境插件化与模块化，降低开发难度，使各个组件的替换变得更加容易，并且提供更好的桌面环境集成支持。

dde-shell 目前包含 shell 本体，以及预制的新 dock 插件和通知中心插件。

treeland / ddm

treeland 目前是技术预览阶段的项目，兼顾 Wayland 窗口合成器和显示管理功能。treeland 除需要 dtk6declarative 外，还依赖新项目包括 waylib 和 qwlroots。需要使用 Qt 版本 >= 6.6.0， wlroots 版本 >= 0.17.0 编译 qwlroots/waylib。

同时我们放弃了对 deepin-kwin wayland 的支持（更新 dde-session 后会屏蔽入口），DDE 所有 wayland 相关的支持均由 Treeland 提供。

deepin-im

treeland 目前是技术预览阶段的项目，提供了输入法的抽象层。目前，deepin-im 仅期望在 treeland 环境下使用。它会设置 QT_IM_MODULE 等环境变量的值来影响实际使用的输入法模块。

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

• Matrix 群：#dde-port:deepin.org
• Telegram 群：https://t.me/ddeport

本月对 NixOS DDE 做了进一步完善，已经比较适合在实体机上使用了。

现在 deepin v23 的版本即将发布，github 大部分 DDE 软件已经升级到了 23 版本，由于 20 和 23 版本不完全兼容，dde-nixos 将使用 v20 分支继续维护/测试 v20 版本的 DDE, main 分支尝试 v23 版本。

目前的主要工作是将 v20 版本的移植工作转移到上游，方便更多用户使用。同时 review 机制也可以找到并处理现有写法的不规范之处。Nixpkgs 合并进程请关注：https://github.com/linuxdeepin/dde-nixos/issues/9

目前已经有一部分应用可在官方仓库下载。

此外 @SamLukeYes 构建了 NixOS DDE 的 iso，可以直接使用： https://github.com/SamLukeYes/nixos-dde-iso/releases/tag/22.11.20230113

• dtk

  • 统一升级到 5.6.3
  • qt5integration 使用 5.6.4 ：修复通知中心图标缺失问题/修复 log 中大量 create icon [] engine failed.[theme:] 问题

• dde-control-center:

  • 禁用系统版权协议模块（仅适配deepin/uos）
  • (dde-api) 修复无法识别本机语言的问题
  • 修改语言（locale）功能在 NixOS 中无法实现，属于正常现象
  • 适配系统版权信息（通过 /etc/deepin-installer.conf 配置实现）
  • 修复明暗主题，图标光标主题缺失（go-lib isDir 判断错误）

• dde-daemon

  • 修复 nix 的 wrapped 应用后无法通过 verifyExe 校验问题
  • 清理无用的硬编码 patch

• deepin-kwin 相关软件：

  • 已经切换至 linuxdeepin 仓库的 tag 版本

• dde-account-faces

  • /var 路径文件改用 systemd.tmpfiles 模块管理

• deepin-system-monitor

  • 修复 dock 插件显示问题

• 配置 Garnix CI

  • 通过 Garnix 自动构建 dde-nixos 的软件，支持 x86 和 arm
  • 使用 Garnix 提供的 binary caches，可以无需编译即可使用 DDE, 用法见项目 readme

• gio-qt

  • 修复文档编译失败

• deepin-boot-maker

  • 修复多处硬编码路径，修复无法识别 u 盘的问题

• dpa-ext-gnomekeyring

  • 修复硬编码

• deepin-font-manager

  • 修复系统字体识别错误

• dde-file-manager

  • 修复新版空格预览崩溃
  • 处理插件硬编码路径

• dde-app-services

  • 修复 GUI 编辑器无法读取其他应用配置问题

• dde-network-core

  • 修复控制中心插件翻译

其他：

• 新增 security.pam.services.dde-lock， 代替 dde-lock 所使用的 common-auth
• 新增 deepin-orc 支持
• 修复对 deepin-anything 的支持
• 默认安装 onboard， dock 插件使用
• 处理 updateDbusEnvironment 未生效的问题：https://github.com/NixOS/nixpkgs/issues/209847
• 清理 dde 模块中非必要启用的 services
• 优化 nix 函数结构，dtk 不再使用列表，改用 propagatedBuildInputs

目前已知的问题：

qt 应用启动器启动不是deepin主题，但通过 deepin-terminal 启动是：

qt5integration 未全局安装，安装后虽然 qt 主题无问题，但是会导致启动器缺失图标等问题。建议 qt 继续使用 breeze 主题

lightdm 不是 deepin 主题

目前 deepin-greeter 无法正常使用，不过使用其他主题或者用 sddm 也是可以启动 DDE 的。

窗口模糊特效缺失

deepin-kwin 的问题，等待修复。通过控制中心关闭再打开特效，可以临时解决。

vscode snipets 用户代码片段使用指南

snipets简介

snipets 我愿意称为程序员的ctrl+c ctrl+v最大的竞争对手，sniptes适用于遇到很多重复代码却又没法去提取代码特点抽象成类的情况。比如写注释的时候。

这是一个极好的工具用于高效率办公（摸鱼）

vscode 打开snipets

然后你就需要选择对应的语言，这里我以doxygen注释文件为例子： 打开之后会得到这样一个文件：

{
 // Place your snippets for doxygen here. Each snippet is defined under a snippet name and has a prefix, body and
 // description. The prefix is what is used to trigger the snippet and the body will be expanded and inserted. Possible variables are:
 // $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders. Placeholders with the
 // same ids are connected.
 // Example:
 // "Print to console": {
 //  "prefix": "log",
 //  "body": [
 //   "console.log('$1');",
 //   "$2"
 //  ],
 //  "description": "Log output to console"
 // }
}

这个文件都是注释组成，自然也没有任何功能，我们要做的是对其进行修改，以支持我们自己的代码片段

代码片段的解读

先以一个比较简单的例子作为内容：

{
 // Place your snippets for doxygen here. Each snippet is defined under a snippet name and has a prefix, body and
 // description. The prefix is what is used to trigger the snippet and the body will be expanded and inserted. Possible variables are:
 // $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders. Placeholders with the
 // same ids are connected.
 // Example:
 // "Print to console": {
 //  "prefix": "log",
 //  "body": [
 //   "console.log('$1');",
 //   "$2"
 //  ],
 //  "description": "Log output to console"
 // }
 "dox dtkwidget": {
  "prefix": "da",
  "body": [
   "@fn void Dtk::Widget::DAlertControl::${2:function}",
   "@brief ${3:info}"
  ]
 }
}

我们来逐行解释：dox dtkwidget指的是这个代码片段的命名，你可以使用任何你喜欢的命名来代替它

然后就是一个键值对 “prefix” 的值一般是一个字符串，这个字符串也是可以自定义的，含义就是你在代码文件里面输入这个字符串（在某一行的开头）后会弹出选项询问你是否使用代码片段：比如这个就是da,你在某一行的开头打出da这俩字符，就会弹窗询问你是否替换

同时会显示对于代码片段的命名

body键值对就是最重要的一部分，这个里面就保存的你需要的代码片段，

请注意，其中每一行都代表的是你之后生成的代码的一行，如上代码片段生成的代码就是

@fn void Dtk::Widget::DAlertControl::function
@brief info

如果你现在已经复制了我的代码片段，不妨新建一个dox文件试试。打出da之后会弹出选项，按tab键确认之后就会出现这个代码，不过会让你填写function的值，填写完毕之后就按tab键切换到info需要你填写info的值

不过这样还不是代码片段的全部实力，它还能更强大点：

 "dox about dtkwidget": {
  "prefix": "dd",
  "body": [
   "@property ${1|QColor,void,bool|} Dtk::Widget::DAlertControl::${2:function}",
   "@brief 返回${3:info}",
   "",
   "@fn void Dtk::Widget::DAlertControl::set${2/(.*)/${1:/capitalize}/i}",
   "@brief 设置${3:info}",
   "@sa DAboutDialog::${2:function}"
  ]
 }

比如这样

你可以自己试试这个会发生什么

对的 它还支持正则表达式的替换

现在看看我正在用的doxygen的代码片段

{

 "dox about DtkGui": {
  "prefix": "dd",
  "body": [
   "@property Dtk::Gui::DDciIconPalette::${2:function}",
   "@brief ${2}属性",
   "@sa READ方法: void Dtk::Widget::DDciIconPalette::${2:function}",
   "@sa WRITE方法: void Dtk::Widget::DDciIconPalette::set${2/(.*)/${1:/capitalize}/i}",
   "",
   "@fn ${1|QColor,void,bool|} Dtk::Widget::DDciIconPalette::${2:function}",
   "@brief 返回${3:info}",
   "@sa DDciIconPalette::${2:function}",
   "",
   "@fn void Dtk::Widget::DDciIconPalette::set${2/(.*)/${1:/capitalize}/i}",
   "@brief 设置${3:info}",
   "@sa DDciIconPalette::${2:function}"
  ]
 },
 "dox dtkwidget": {
  "prefix": "da",
  "body": [
   "@fn void Dtk::Widget::DDciIconPalette::${2:function}",
   "@brief ${3:info}"
  ]
 }
}

我可以通过这个代码片段一键生成属性的get和set方法的doxygen注释