• 首页
  • 加入
  • RSS
  • Tuesday, May 30, 2023

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

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

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

    一、目标描述

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

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

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

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

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

    了解了Qt 插件标准(Qt 插件标准

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

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

    阅读整理了各个论坛中关于deepin开机自启动项的讨论(169824124825726

    三、系统框架设计

    1、项目整体结构设计

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

    类图

    2、类功能说明

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

    3、实现描述

    (1)插件类

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

    名称功能
    SelfStarupPlugin类的初始化函数
    pluginName返回插件名称,用于在 dde-dock 内部管理插件时使用
    init插件初始化入口函数,参数 proxyInter 可认为是主程序的进程
    pluginDisplayName返回插件名称,用于在界面上显示
    itemWidget返回插件主控件,用于显示在 dde-dock 面板上
    itemPopupApplet返回鼠标左键点击插件主控件后弹出的控件
    flags用于返回插件的属性,例如插件显示的位置,插件占几列,插件是否支持拖动等
    pluginIsAllowDisable返回插件是否允许被禁用(默认不允许被禁用)
    pluginIsDisable返回插件当前是否处于被禁用状态
    pluginStateSwitched当插件的禁用状态被用户改变时此接口被调用
    itemContextMenu返回鼠标左键点击插件主控件后要执行的命令数据
    invokedMenuItem返回鼠标右键点击插件主控件后要显示的菜单数据

    (2)部件类

    名称功能
    MainWidgetMainWidget部件的初始化函数,设置dde-dock图标的基础样式与文字内容
    ~MainWidgetMainWidget部件的析构函数
    sizeHint设置图标大小的函数
    插件图标

    图标

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

    (3)自启动管理窗口

    名称功能
    AppletWidgetAppletWidget的初始化函数,负责绘制与用户交互的开机自启动项展示表格与修改设置选项
    ~AppletWidgetAppletWidget部件的析构函数
    searchAll搜索所有可设置开机自启动的软件
    update更新被自启动的软件
    readfiles工具函数,用于读取文件中的内容
    disable禁用开机自启动设置的后端接口
    enable启用开机自启动设置的后端接口
    add添加开机自启动设置的后端接口
    delete删除开机自启动设置的后端接口
    getFileName通过绝对路径找到文件的名字
    getAllFiles递归获取到某目录中所有文件
    globalSearch在所有文件中找到.desktop类型文件
    Manual寻找拟添加软件的函数,给用户在系统中寻找想要添加自启动项的软件
    showAppsDebug工具,在Debug信息中打印软件名称
    showPathsDebug工具,在Debug信息中打印路径名称
    onButtonClicked自启动管理窗口启用/禁用按钮的处理函数
    addButtonClicked自启动管理窗口添加按钮的处理函数
    delButtonClicked自启动管理窗口删除按钮的处理函数
    自启动管理窗口的前端页面

    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_pathselfSetUp中删去该部分信息

    四、开发计划

    第一步(4/9~4/18)

    • 调研Deepindde-dockQT框架等相关内容
    • 设计项目方案
    • 分工

    第二步(4/19~5/2)

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

    第三步(5/3~5/13)

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

    第四步(5/14~5/21)

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

    第五步(5/22~5/31)

    • Debug
    • 撰写文档

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

    日期进展
    4/17完成开发环境配置
    4/27完成插件框架设计
    5/3完成自启动管理界面的实现
    5/8完成自启动管理接口实现的讨论
    5/12完成自启动操作项的接口设计与实现
    5/21完成配置文件,并通过cmake编译
    5/22完成图标的Debug,前端界面展示正常
    5/29完成自启动操作接口Debug

    六、系统测试情况

    1、前端测试

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

    sh install.sh
    

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

    结果

    右键功能展示正常:

    右键

    2、自启动管理功能测试

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

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

    1、开发环境配置

    (1)、配置 Deepin 操作系统

    开发环境:Deepin 20Beta版

    系统架构:x86

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

    虚拟机平台:WMware Workstation 16Pro

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

    (2)、配置 Deepin 插件开发环境

    安装基本开发环境:

    安装包 build-essentialgitg++cmakeddedtk

    sudo apt install build-essential git g++ cmake
    sudo apt install dde-dock-dev libdtkwidget-dev
    
    安装 QT 开发环境:

    安装 qt5-defaultqt5-docqtcreator

    sudo apt install qt5-default qt5-doc qtcreator
    

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

    image-20230513155011159

    (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系统自带的修改开机自启动设置的方法,修改开机启动项(图中修改终端的自启动项):

    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

    十、比赛收获

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

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

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

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

    Monday, May 29, 2023

    【摘要】arm64架构支持 v23仓库已经支持arm64和amd64架构软件包,arm64架构的基础环境已经具备,现在就差镜像制作工具的支持了,镜像构建工具的目标是构建出标准pc镜像。为此我借来一台紫光 飞腾D2000机器进行arm64的适配工作,这台机器有相对标准的UEFI固件,目前已经支持UEFI安装, 阅读全文

    Sunday, May 14, 2023

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

    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 的版本参照如下:

    packageversion
    dtkcommon5.6.29
    dtkcore5.6.29
    dtkgui5.6.29
    dtkwidget5.6.29
    dtkdeclarative5.6.29
    qt5integration5.6.29
    qt5platform-plugins5.6.29
    dtk6core6.0.16
    dtk6gui6.0.16
    dtk6widget6.0.16
    dtk6declarative6.0.16
    qt6integration6.0.16
    qt6platform-plugins6.0.16

    本次 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 进行打包与移植。

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

    packageversion
    dde-session1.2.9
    dde-application-manager1.2.12
    dde-shell0.0.23
    dde-launchpad0.6.12
    dde-application-wizard0.1.5
    dde-dock被 dde-shell 取代,不再使用

    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 外,还依赖新项目包括 waylibqwlroots。需要使用 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 移植小组的在线交流群(下列房间有桥接,任选其一即可),一起展开相关的交流:

    Monday, April 10, 2023

    目前 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

    1. 改善对交叉编译

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

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

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

    Friday, April 7, 2023

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

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

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

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

    Thursday, March 9, 2023

    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 并进行有效的修复成为了获胜的关键之一,根据表象快速分析推测问题的能力,以及在陌生项目1中快速尝试定位和修复问题的能力也变得至关重要。作为花絮,有的小组也在选择 BUG 的过程中连续发现自己所选择的缺陷实际早已在版本迭代中被修复,耗费了较多时间而造成了相对的失利,但这个过程也对现存 BUG 的有效性验证有很大的帮助2

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

    荣誉证书

    颁奖截图

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


    1. 注:缺陷的修复不限于自己所维护的项目,研发人员也可以尝试修复由其他项目组所维护的缺陷。 ↩︎

    2. 或许在后续的比赛中应当为此类也算作计分项。 ↩︎

    Tuesday, February 14, 2023

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

    Friday, February 3, 2023

    【摘要】pbuilder + qemu 以下操作基于debian11环境,其他环境下需注意qemu版本是否在5.2版本以上 sudo apt install pbuilder qemu qemu-user-static pigz 配置 /etc/pbuilderrc MIRRORSITE=https://m 阅读全文

    Thursday, February 2, 2023

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

    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 的版本参照如下:

    packageversion
    dtkcommon5.6.21
    dtkcore5.6.22
    dtkgui5.6.22
    dtkwidget5.6.22
    dtkdeclarative5.6.24
    qt5integration5.6.20
    qt5platform-plugins5.6.22
    dtk6core6.0.4
    dtk6gui6.0.5
    dtk6widget6.0.4
    dtk6declarative6.0.7
    qt6integration6.0.4
    qt6platform-plugins6.0.4

    由于 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 外,还依赖新项目包括 waylibqwlroots。需要使用 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 移植小组的在线交流群(下列房间有桥接,任选其一即可),一起展开相关的交流:

    Monday, January 30, 2023

    本月对 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 的问题,等待修复。通过控制中心关闭再打开特效,可以临时解决。