在 V23 beta 版本中，DDE 试验性的开启了 Wayland 的支持，允许用户在 Wayland 协议下的桌面工作环境启动 。本篇文章会向大家介绍一下 Wayland 是什么，我们尝试做了什么改变，以及 DDE Wayland 未来会支持哪些新特性。（注：单独提出 Wayland， 通常和 Wayland 合成器、Wayland 服务器、显示服务器被视为同一个内容；X Window System 和 X11 也被视为同一个内容。）

什么是 Wayland？

Wayland 是一个通信协议，规定了显示服务器与客户端之间的通信方式，而使用这个协议的显示服务器称为 Wayland Compositor。Wayland 只专注于图形，并希望使用其他库与输入硬件进行通信，以降低自身的复杂度。Wayland 最大的好处也是大家都推崇的原因，那就是 Wayland 在设计上会考虑安全，例如默认不允许窗口获取其他窗口的数据，合成器和窗口管理器的合并也降低了对系统资源的消耗。

Wayland 与 X Window System 有什么不同？

Wayland 与 X Window System 的最大不同在于，Wayland 与 X Window System 的最大不同在于，它的窗口管理器和 Wayland Server 在同一个进程，并且客户端能够通过 EGL 以及一些 Wayland 特定的 EGL 扩充组件直接在显示内存中绘制自己的缓冲区。 窗口管理器简化成显示管理服务，专门负责绘制那些屏幕上的程序。 这比 X Window System 中的窗口管理器要更简单、高效。

Wayland 协议有哪些组成？

1.协议概述

Wayland 协议被描述为异步面向对象协议。协议是异步的，这意味着不必等待回复或者响应 ACK，避免了往返时间并提高性能。协议封装为面向对象的设计，则是面向对象的设计方式，能很好的对服务器上不同窗口数据及接口进行封装。

Wayland 合成器可以定义和公开自己的附加接口，被称为扩展协议，不同的 Wayland 会提供功能完全不同，甚至功能相反的协议，这带来了很大灵活性，但使用客户端时需要自行判断。

2.协议架构

Wayland 协议是一种“客户端 —— 服务器”模型，客户端是请求在屏幕上显示画面的图形应用程序，服务器是控制应用程序显示在屏幕上的管理程序。Wayland 参考实现被设计成两层协议，既：

• 下层协议：处理客户端和服务器之间的进程间通信，以及在内部的数据封装处理。
• 上层协议：处理客户端和服务器交换的数据，以实现窗口系统的基本功能，这一层被实现为异步面向对象协议。 下层协议是使用 C 语言开发的，而上层协议是根据 XML 格式的协议描述文件自动生成，每当 XML 协议的描述发生变化时，就可以重新生成该协议的源代码，这使得协议非常灵活、可扩展性好且防止出错。

如下 Wayland 工作原理图：

以下对应图中所标编号作说明：

①Linux 内核中的 evdev 模块接收事件并将它们发送到 Wayland 合成器。

②Wayland 合成器查看场景图并确定哪个窗口应接收事件。场景图对应于屏幕上显示的内容，Wayland 合成器显示对应用事件的场景图中元素的转换。因此，Wayland 合成器可以反向变换以找到正确的窗口，并将屏幕上的坐标转换为窗口中的坐标。

③当客户端收到事件时，Wayland 的客户端只需通过 EGL 渲染并向合成器发送请求以通知更新的范围即可。

④Wayland 合成器 从客户端收集更改请求并重新配置屏幕。 然后，合成器直接发出 ioctl 让 KMS 重绘屏幕。

当了解了 Wayland 相关基本介绍之后，基于它我们在 DDE 上将会作哪些适配功过呢？将从以下几个方面说一下我们在 Wayland 技术预览版里面所做的适配工作。

DDE 适配 Wayland 都做了哪些工作

DDE 原本设计为在 X11 协议下工作，很多组件直接或间接依赖 X11 的接口，多数组件依赖的功能并没有在 XWayland 中提供，所以就需要进行一些修改。

首先在 Qt 插件中实现和 Wayland 特定性相关的功能，Qt 提供了一个 Wayland Shell Integration 的插件，允许我们在这里调用 DDE Wayland 合成器提供的扩展协议。

Qt 已提供核心协议的适配，所以 DDE 只需要在现有框架下实现扩展协议即可。

目前 DDE 提供的扩展协议有以下几个方面：

• 设置圆角窗口
• 请求获取窗口数据（截图权限）
• 划分工作区可用区域 DTK 程序可以通过设置窗口的属性，或者使用 DTK 提供的平台接口，即可调用扩展的 Wayland 协议，非 DTK 程序则需要手动使用扩展协议的 XML 文件进行代码生成调用。

DDE Wayland 未来会支持什么特性？

1.HDR 支持

高动态范围（HDR）是比平时更高的动态范围。HDR 的内容过于深入，在这里只简单的进行说明。

HDR 可以保存更多的内容信息，在支持 HDR 的屏幕上观看 HDR 的内容，可以获得更好的体验，DDE 目前正在准备支持 HDR 内容的输出，这会让 DDE 拥有更好的显示效果。

2.成体系的窗口动画

在 X11 下，由于窗口管理和画面合成管理是两个进程，并且在启动速度上存在差异，所以只能采用一些“巧妙”的设计来规避视觉错误。

但是在 Wayland 下，窗口管理器和窗口合成器被合并成一个进程，那么启动后就可以立即使用动画效果，例如可以设计视觉效果更好的登录动画。

目前 DDE 的窗口动画支持并不多，且大部分是单调的线性动画，有些情况还需要客户端自己实现虚假动画，例如任务栏发生位置变化时，桌面的图标会进行计算，并自行改变大小，这引入了非必要的依赖。如果使用窗口动画，桌面并不需要关心任何外部因素，只需要设置自己在可用工作区域最大化，当任务栏发生位置改变时，合成器会自动调整桌面的大小，并产生相应的窗口动画。

未来 DDE 会使用更多窗口动画来减少组件之间的依赖，以及实现更多更好的视觉效果。

最后总结

阅读至此，是不是对 Wayland 的概念及工作原理更加清晰啦？如果您有什么疑问也欢迎与我们互动探讨 Wayland。

坦白说，DDE 的 Wayland 支持还处于初步阶段（技术预览版，请谨慎使用），未来我们会使用更多合成器提供的功能，来为桌面环境降低开发难度，提升性能。提供更好的体验。

队员：复旦大学 朱元依、沈扬、朱俊杰
指导老师：张亮、陈辰
企业导师：王子冲

本项目为2023年操作系统大赛企业赛道赛题。

项目链接：DDE 自启动管理插件 github仓库

一、目标描述

我们小组的选题为proj223-control-center-startup-management-plugin

DDE 深度桌面环境的控制中心提供了插件功能，以便第三方开发者可以扩展其功能并额外的功能组件添加到控制中心之中。我们将在本项目中为 DDE 桌面环境的控制中心编写一个自启动管理插件。

二、比赛题目分析和相关资料调研

为了明确题目设置的原因与需求，我们请教了了企业导师，得知：目前用户对自启动权限的管理目前只能通过 dde-launcher （启动器/“开始菜单”）的右键菜单进行管理；考虑到此功能本身也并不复杂，所以设置了此课题，旨在解决这样的问题。

而对于此开发任务的具体实施，主要需要对dde-dock插件运行的原理和deepin开机自启动的设置方式进行调研，以便进行开发。调研的具体内容包括：

了解了Qt 插件标准（Qt 插件标准）

阅读整理了dde-dock官方仓库中的插件工作原理（插件工作原理）

学习其他开发者的插件项目（CMDU_DDE_DOCK）

阅读整理了各个论坛中关于deepin开机自启动项的讨论（169824、124825726）

三、系统框架设计

1、项目整体结构设计

符合dde-dock提供的接口与插件开发规范，本项目将分为插件类（SelfStartPlugin）、部件类（MainWidget）和自启动管理窗口（AppletWidget）分别进行功能的实现。其中，项目的结构和各对象所包含的数据结构与方法如下图所示：

2、类功能说明

插件类SelfStartPlugin负责实现插件与dde-dock交互所必须的接口；部件类MainWidget负责在dde-dock中展示该插件的图标；自启动管理窗口AppletWidget负责实现核心功能：读取Deepin系统的开机自启动项、同时对各个软件的开机自启动进行管理（包括添加、删除、启用、禁用）。

3、实现描述

（1）插件类

在插件类中，主要实现了dde-dock中 PluginItemInterface相关的接口，便于系统加载并实现插件的功能。接口包括以下内容：

（2）部件类

插件图标

最左侧的SELF_STARTUP图标为该插件图标。

（3）自启动管理窗口

自启动管理窗口的前端页面

在AppletWidget的构造函数中，我们实现了便于用户查看系统开机自启动设置信息列表、并便于管理的前端展示页面：

开机自启动管理的后端接口

该部件中，主要设置了四个函数接口实现与操作系统的交互，分别是searchAll、update、disable、enable

首先要在MainWidget启动的时候在/home中读到用户名username

searchAll()

在opt/apps中找到所有用户下载程序的文件夹，读入文件夹名称subdir，再到opts/appp/subdir/entries/application中找到.desktop启动文件，解析文件内容，读入name字段并把name - path存到MainWidge类中，并且返回所有找到的app名称

update()

根据启动时读到的username在/data/home/username/.config/autostart里面找到里面所有的.desktop文件，分别读取并获取状态Hidden是否为false，把所有Hidden字段为False的插件（被设置成了开机自启动）在MainWidget的selfSetUp成员中设置为pair<name, true>

disable()

功能设计为禁用自启动。通过name_path中对name的索引找到路径path，对设置为自启动的应用path会在/data/home/username/.config/autostart/*.desktop中。读取该.desktop文件修改Hidden字段为True即可

enable()

功能设计为启用自启动。对于之前添加过的应用，name_path中得到的路径是在/data/home/username/.config/autostart中，此时与disable()过程相同，把Hidden字段设置成false即可；对于之前没有添加过的应用，name_path中的路径会在opts/appp/subdir/entries/application/appname/entries/application/*.desktop中，并且该文件是只读的。需要读取该文件并写入到/data/home/username/.config/autostart/*.desktop中，并且在文件的第一个分区里面写入一行"Hidden=false"

Add()

用户点击后打开文件资源管理器对话框，从中选择希望添加的可执行文件并返回文件路径。如果该文件是一个.desktop类型文件则添加到autostart中，如果不是则会在autostart中创建一个新的.desktop文件，并且把Exec=行设置为该可执行文件的路径

Delete()

从管理窗口中删除某应用的管理。传入参数是应用名称，找到该应用的.desktop文件路径并从autostart中删除，并且在数据结构name_path和selfSetUp中删去该部分信息

四、开发计划

第一步（4/9～4/18）

• 调研Deepin、dde-dock、QT框架等相关内容
• 设计项目方案
• 分工

第二步（4/19～5/2）

• 搭建主体插件类的框架
• 设计启动项管理窗口的前端展示页面

第三步（5/3～5/13）

• 开发部件类接口
• 完善插件类功能

第四步（5/14～5/21）

• 插件类右键功能开发
• 完成配置文件

第五步（5/22～5/31）

• Debug
• 撰写文档

五、比赛过程中的重要进展

六、系统测试情况

1、前端测试

在项目总路径下运行install.sh脚本，可完成插件的编译与安装：

sh install.sh

该脚本使用cmake编译代码，并安装到dde-dock插件文件夹中。运行后，可以正常展示自启动管理页面。点击加号后，用户可以在弹窗中选择想要添加自启动项的软件。

右键功能展示正常：

2、自启动管理功能测试

以浏览器为例。根据自启动管理窗口的设置，我们尝试添加并启用浏览器的自启动项。关机重启后，浏览器完成自启动。同理，删除、禁用功能均通过测试。

七、遇到的主要问题和解决方法

1、开发环境配置

（1）、配置 Deepin 操作系统

开发环境：Deepin 20Beta版

系统架构：x86

镜像下载链接：Deepin 操作系统下载链接

虚拟机平台：WMware Workstation 16Pro

操作系统环境搭建参考博客：环境搭建博客

（2）、配置 Deepin 插件开发环境

安装基本开发环境：

安装包 build-essential、git、g++、cmake、dde、dtk

sudo apt install build-essential git g++ cmake
sudo apt install dde-dock-dev libdtkwidget-dev

安装 QT 开发环境：

安装 qt5-default、qt5-doc、qtcreator

sudo apt install qt5-default qt5-doc qtcreator

依照上述方法，可在虚拟机中运行qtcreator，并在qtcreator中对插件进行测试

（3）、插件安装测试

为了测试所配置的虚拟机环境可用于 DDE 插件的开发，在环境配置中，本小组选取了Github仓库中的插件dde-sys-monitor-plugin（项目地址：dde-sys-monitor-plugin插件仓库）进行试运行。

根据上述方法配置插件开发环境后，可按照dde-sys-monitor-plugin中的提示信息顺利运行该插件。这表明开发环境配置已完成。

（4）环境配置中遇到的问题

安装sudo apt install libdtkwidget-dev libdtkgui-dev libdtkcore-dev出错

正试图覆盖 /usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/dtk_install_dconfig.prf，它同时被包含于软件包 libdtkcommon-dev 5.5.23-1

在处理时有错误发生：

/var/cache/apt/archives/libdtkcore-dev_5.6.4-1+rb1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

解决方法：

使用sudo apttitude install libdtkwidget-dev libdtkgui-dev libdtkcore-dev 选择第二种解决方式（先卸载nY再重新安装sudo apt install libdtkwidget-dev libdtkgui-dev libdtkcore-dev）

2、开机启动项处理思路

为了实现插件可视化管理软件的开机自启动，了解Deepin系统开机自启动的功能实现是至关重要的。

通过查阅资料与实践，我们了解到Deepin系统包含自启动文件夹~/.config/autostart，该文件夹类似于 Windows 下的启动文件夹，系统开机时会执行该文件夹下的每个 desktop 文件 Exec 参数指向的脚本或可执行文件。

为了确认可行性，小组进行了该方法的验证。首先，通过Deepin系统自带的修改开机自启动设置的方法，修改开机启动项（图中修改终端的自启动项）：

随后检查自启动文件夹~/.config/autostart：

yang@yang-PC:~/.config/autostart$ ls
deepin-terminal.desktop org.deepin.browser.desktop

发现deepin-terminal.desktop文件被添加入了该自启动文件夹中，并且会在开机时自启动。

而取消终端的自启动时，~/.config/autostart中已有的deepin-terminal.desktop文件并不会被移除，而是其中的Hidden的字段会被修改为false，表示取消开机自启动设置。

由此，可以通过在插件中检查所有~/.config/autostart文件夹中.desktop文件的Hidden字段来搜索系统所有的自启动软件；也可以通过添加.desktop文件、修改Hidden字段的方式进行开机自启动设置的修改。

3、与 deepin 接口设计

（1）、关于开机自启动项

在查找deepin如何实现开机自启动时，看到了在deepin文件夹中有多个名为autostart的文件夹，其中有一部分包含了系统文件（例如终端、输入法等），但是在我们通过“开始”菜单修改其是否自启动性质时发现并为出现变化，并且我们自行在“应用商店”里面下载的软件并没有在设置为开机自启动后进入到该文件夹。经过在网络上搜索了关于deepin开发的一些讨论资料以及学习了一些关于启动文件.desktop文件功能并通过vscode对是否开机自启动设置后的文件进行比较后，找到了文件路径位于/data/home/username/.config/autostart中，并且在文件中有Hidden字段使得不用每次取消自启动是都要删除文件并且下次设置又重新加入

（2）、关于查找应用程序

一开始的想法是在系统目录下整体查找，找到系统中所有的.desktop文件，但显然这样过于繁琐且效率低下。后来在通过打开每个引用的.desktop文件后发现exec项均在/opt/apps中，打开该文件夹可以发现里面有所有用户下载的应用程序及其依赖等文件的文件夹，并在打开每个文件夹后可以找到启动文件均在entries/application中，并且可能有多个.desktop文件，所以把自启动的工作变为了对启动器文件用文本方式打开后的解析与修改

（3）、关于函数接口设计

对QT库中的数据类型和class的使用不太熟悉，需要根据官方文档对提供的api和C++模式的代码进行替换。但熟悉使用之后理解到了QT数据类型的多样性以及提供的方法会更加完备，在做开发时避免了很多自己重写方法的复杂流程。

4、cmake中遇到的问题

（1）、cmake 出现 dbus、core 找不到

解决方法：find_package()的REQUIRED后面新增找不到的对应的包

（2）、cmake 出现 FOUND=FALSE

  /usr/lib/x86_64-linux-gnu/cmake/DtkWidget/DtkWidgetConfig.cmake                                                                                                                   
  but it set DtkWidget_FOUND to FALSE so package "DtkWidget" is considered to                                 
  be NOT FOUND. 

解决方法：使用.pro文件设置cmake需要的相关参数。

八、分工和协作

朱元依：插件类框架开发、部件类前端开发

沈扬：自启动管理功能逻辑设计、插件类右键功能开发

朱俊杰：自启动管理窗口后端接口开发（添加、删除、启用、禁用）

九、提交仓库目录和文件描述

.
├── CMakeLists.txt
├── README.md
├── aboutdialog.cpp    #关于窗口的实现文件
├── aboutdialog.h     #关于窗口的头文件
├── aboutdialog.ui     #关于窗口的UI文件
├── appletwidget.cpp   #自启动管理窗口的实现文件
├── appletwidget.h    #自启动管理窗口的头文件
├── images        #图片
│ ├── QT_IDE.png
│ ├── QT_前端.png
│ ├── deepin自启动修改.png
│ ├── 类图.jpg
│ ├── 右键.png
│ ├── 图标.png
│ ├── 结果.png
│ ├── 中期类图.jpg
│ ├── 中期测试.png
│ └── 前端界面.png
├── install.sh        #插件安装脚本
├── main_aboutdialog_test.cpp #关于窗口的测试文件
├── main_test.cpp      #测试文件
├── mainwidget.cpp     #插件类的实现文件
├── mainwidget.h      #插件类的头文件
├── self_startup.json     #插件的元数据文件，指明了当前插件所使用的 dde-dock 的接口版本
├── self_startup.pro     #辅助 cmake 的配置文件
├── self_startup.qrc     #用于展示插件图片
├── selfstartupplugin.cpp   #部件类的实现文件
├── selfstartupplugin.h    #部件类的头文件
├── uninstall.sh        #插件卸载脚本
├── 初赛报告.md
└── 过程文档.md

十、比赛收获

借由为deepin的dde-dock编写插件的机会，我们小组了解了deepin系统相关的接口、dde-dock插件加载原理、开发逻辑等等操作系统相关的知识；同时我们在合作开发的过程中熟悉了软件工程的开发规范。小组同学在比赛中均受益匪浅。

十一、与企业导师的沟通情况

我们已于企业导师（王子冲）通过电子邮件进行联系。王导师向我们推荐了 deepin 开源社区各种公开渠道（如实时聊天渠道 Matrix、开发者社区讨论板等），鼓励我们在开发过程中将所遇到的问题在社区研发话题板块中进行公开探索。

此外，王导师还耐心的向我们介绍了该课题的设置原因，这对与我们在项目设计的过程中了解用户需求起到了很大的作用。

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

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，有改动）。若你有任何建议，可以进行讨论并修改或提供更适合的主题。