感谢分享。
打包成deb/玲珑包直接上架官方商店呗!
打包成deb/玲珑包直接上架官方商店呗!
虽然还没实际试过,但是感觉打包玲珑目前应该不太可行吧?因为需要调用宿主环境的 distrobox 可执行。
打包成 deb 是已经有了,不过没上商店,还是希望先收集一些反馈再决定是否要在这个项目上投入更多精力/大家觉得要做哪些事情是有意义的之类。
这么好到东西,要不要和你们领导说说,进linuxdeepin里好了。然后就叫dde-distrorack或deepin-distrorack,就可以直接进入仓库了
支持支持
感谢大佬分享,推荐一个,希望可以帮到更多的开发者们

牛的牛的
国内的话建议也支持下Gitee
虽然还没实际试过,但是感觉打包玲珑目前应该不太可行吧?因为需要调用宿主环境的 distrobox 可执行。
打包成 deb 是已经有了,不过没上商店,还是希望先收集一些反馈再决定是否要在这个项目上投入更多精力/大家觉得要做哪些事情是有意义的之类。
目前deb更合适一些
强!
先star 一下 。deepin 需要这类的gui应用
你认为这个项目有意义吗?
有,真的懒得记指令
是否真的解决了 distrobox 的问题?
是
你会考虑使用它吗?
不会,我会用自己搓的轮子,我认为全自动创建entry就可以了,没必要让用户手动再创建一下,且没必要运行一个后台持续执行的容器
如果你会 C++/QML,你会考虑为这个项目做代码贡献吗?
不会写捏
你方便访问 GitHub 吗?如果不方便,倾向于放在哪里下载?
不方便,Gitee
提供国内 Git 镜像并接受来自镜像位置的代码贡献(比如 gitee/gitlink 之类)的话,你会更乐意贡献代码吗?如果会,你倾向于哪个平台?
我倾向于gitee,但是我不会写cpp
你有兴趣打赏作者吗?如果没有也没问题,但是如果有的话,是哪种途径?以及你希望以某种形式展示打赏人员的名单吗?
直接微信支付宝码是最高效的,抽成很蛋疼的。可以在关于页面展示,但是DTK的DAboutDialog....一言难尽,单独做一个吧
你觉得“更契合 DTK/DDE 样式外观“这点重要吗?
主要是不用DTK的话还要额外设计一套UI,用DTK可以保底不会太丑,建议用dtk
如果你试用过了当前状态的版本,有什么想要反馈的内容吗?
首先感谢各位支持!
@krisd 国内的话建议也支持下Gitee
看到确实不少期望 gitee 有镜像仓库的,目前加了 gitee 镜像: https://gitee.com/blumia/distro-rack
不过国内的平台的 CI 配额好像都比较惨不能放开用,所以自动构建的版本暂时放不到上面。
@神末shenmo 不会,我会用自己搓的轮子,我认为全自动创建entry就可以了,没必要让用户手动再创建一下,且没必要运行一个后台持续执行的容器
你指的是 ACE 么😏
目前而言 distro-rack 还没有做帮用户(从对应distro的软件源)下软件/装软件/卸软件的相关 GUI 功能,更多是侧重容器管理来体现 distrobox 自有的功能。感觉后面也可以加倒是,也得看到底多少用户需要/是否真的需要(也是这个帖子的目的)。
直接微信支付宝码是最高效的,抽成很蛋疼的。
不知道之前好像哪里看到过说法是个人的码不太适合放出来,但细节记不清楚了...不知道是不是真的有坑。
但我也不知道是不是真的有人打赏支持这种工具倒是。
但是DTK的DAboutDialog....
目前这个用的是 QML 那一套(dtkdeclarative),虽然那个关于对话框也比较蛋疼但是本来也可以另加选项显示这种内容倒是。
主要是不用DTK的话还要额外设计一套UI,用DTK可以保底不会太丑,建议用dtk
其实 dtkdeclarative 东西挺少的,感觉缺 KDE 那边类似 kirigami 的那套东西对等的组件库。其实也可以直接用 kirigami(deepin 仓库有),但是又不太想让 deepin 用户多这么个依赖 = =
首先感谢各位支持!
@krisd 国内的话建议也支持下Gitee
看到确实不少期望 gitee 有镜像仓库的,目前加了 gitee 镜像: https://gitee.com/blumia/distro-rack
不过国内的平台的 CI 配额好像都比较惨不能放开用,所以自动构建的版本暂时放不到上面。
@神末shenmo 不会,我会用自己搓的轮子,我认为全自动创建entry就可以了,没必要让用户手动再创建一下,且没必要运行一个后台持续执行的容器
你指的是 ACE 么😏
目前而言 distro-rack 还没有做帮用户(从对应distro的软件源)下软件/装软件/卸软件的相关 GUI 功能,更多是侧重容器管理来体现 distrobox 自有的功能。感觉后面也可以加倒是,也得看到底多少用户需要/是否真的需要(也是这个帖子的目的)。
直接微信支付宝码是最高效的,抽成很蛋疼的。
不知道之前好像哪里看到过说法是个人的码不太适合放出来,但细节记不清楚了...不知道是不是真的有坑。
但我也不知道是不是真的有人打赏支持这种工具倒是。
但是DTK的DAboutDialog....
目前这个用的是 QML 那一套(dtkdeclarative),虽然那个关于对话框也比较蛋疼但是本来也可以另加选项显示这种内容倒是。
主要是不用DTK的话还要额外设计一套UI,用DTK可以保底不会太丑,建议用dtk
其实 dtkdeclarative 东西挺少的,感觉缺 KDE 那边类似 kirigami 的那套东西对等的组件库。其实也可以直接用 kirigami(deepin 仓库有),但是又不太想让 deepin 用户多这么个依赖 = =
国内的平台的 CI 配额好像都比较惨不能放开用,所以自动构建的版本暂时放不到上面
目前我采用的方案是gitee同步到github,代码用gitee写,白嫖github actions 的方法,主打一个好处都占了坏处都不沾
https://github.com/GXDE-OS/GXDE/actions
https://gitee.com/GXDE-OS/
你指的是 ACE 么😏
生命在于折腾,自己搓的轮子自己用
如果我有distrobox的需求我会很喜欢rack,逻辑简单清楚,很好的产品
下软件/装软件/卸软件的相关 GUI 功能
我的建议是让小白归小白pro归pro,图形化软件管理应该交给应用商店,用distrobox管理器的目的是管理distrobox而不是解决兼容性问题,那是商店做的事
不知道之前好像哪里看到过说法是个人的码不太适合放出来,但细节记不清楚了...不知道是不是真的有坑
同插眼
那个关于对话框也比较蛋疼但是本来也可以另加选项显示这种内容倒是
愿闻其详?
我想加个可以放图片的放一下星火吉祥物
其实也可以直接用 kirigami(deepin 仓库有),但是又不太想让 deepin 用户多这么个依赖
除非你想一边搓dtk一边做,否则没必要,用户不差这一个依赖
还要考虑下其他distro的用户可能也喜欢这个,毕竟做得很好,所以引入kde依赖没什么,反而是最新的dtk可能会带来麻烦
虽然还没实际试过,但是感觉打包玲珑目前应该不太可行吧?因为需要调用宿主环境的 distrobox 可执行。
打包成 deb 是已经有了,不过没上商店,还是希望先收集一些反馈再决定是否要在这个项目上投入更多精力/大家觉得要做哪些事情是有意义的之类。
玲珑可以用 host-spawn,这边不方便fq,可以在github找到源码,在玲珑中可以用,目前ACE的交互式提权和xdg-open转发都用的这个
这里有构建好的
https://gitee.com/amber-ce/ace-common/tree/master/src/opt/apps/@PKG_NAME@/files/amber-ce-tools/bin-override
@神末shenmo 目前我采用的方案是gitee同步到github,代码用gitee写,白嫖github actions 的方法,主打一个好处都占了坏处都不沾
目前我也是了,只是针对用户而言让用户下 CI 版还是相当于从 GitHub 的位置下载,肯定是不太合理的。Release 倒是可以在 gitee 发,不过目前还没有过 tag release,只有 CI 版,比较尴尬。
我的建议是让小白归小白pro归pro,图形化软件管理应该交给应用商店,用distrobox管理器的目的是管理distrobox而不是解决兼容性问题,那是商店做的事
确实认同这个观点,不过商店目前应该没有提供“在distrobox中安装软件”这种性质上的功能,恐怕商店也没这个计划...吧。
那个关于对话框也比较蛋疼但是本来也可以另加选项显示这种内容倒是
愿闻其详?
D.AboutAction {
aboutDialog: D.AboutDialog { ... }
}
aboutDialog
这个属性应该可以改成任意对话框,另外 AboutDialog 也有个 companyLogo
属性,虽然我没试但是这个或许你能用。我觉得你可以考虑...
- 试试 AboutDialog 的 companyLogo 属性
- 干脆自己提供个对话框,里面爱放啥放啥,爱咋放咋放(
我想加个可以放图片的放一下星火吉祥物
顺带羡慕一下有吉祥物。目前这个项目连个 logo 都没有,目前是直接用了 distrobox 附带的图标((
除非你想一边搓dtk一边做,否则没必要,用户不差这一个依赖
还没看星火商店的代码,你们是有用 kirigami 吗?主要问题在于不太清楚 kirigami 应用在 Chameleon 主题下会不会很惨,所以也不太敢用。即便是目前保持尽可能用 Qt QuickControls 2 自带控件的情况都发现了一些问题,比如 GroupBox 标签背景永远是白色的,这个问题我搓 distro-rack 的时候才发现,这个 dtk6declarative 的问题我今天才修掉。
还要考虑下其他distro的用户可能也喜欢这个,毕竟做得很好,所以引入kde依赖没什么,反而是最新的dtk可能会带来麻烦
这个反而是事先就考虑到的了。目前 DDE 相关的样式是完全运行时的 QML import,并且是根据 XDG_CURRENT_DESKTOP
环境变量决定是否使用 DDE 样式的。对于非 DDE 环境下,完全不会尝试 import,外观则目前会用一个很朴素的通用样式(因为只用到了 QQC2 的组件),目前是这个样子:
玲珑可以用 host-spawn
喔,原来玲珑有啊,那看来是可行的了。回头瞅瞅看。
@神末shenmo 目前我采用的方案是gitee同步到github,代码用gitee写,白嫖github actions 的方法,主打一个好处都占了坏处都不沾
目前我也是了,只是针对用户而言让用户下 CI 版还是相当于从 GitHub 的位置下载,肯定是不太合理的。Release 倒是可以在 gitee 发,不过目前还没有过 tag release,只有 CI 版,比较尴尬。
我的建议是让小白归小白pro归pro,图形化软件管理应该交给应用商店,用distrobox管理器的目的是管理distrobox而不是解决兼容性问题,那是商店做的事
确实认同这个观点,不过商店目前应该没有提供“在distrobox中安装软件”这种性质上的功能,恐怕商店也没这个计划...吧。
那个关于对话框也比较蛋疼但是本来也可以另加选项显示这种内容倒是
愿闻其详?
D.AboutAction {
aboutDialog: D.AboutDialog { ... }
}
aboutDialog
这个属性应该可以改成任意对话框,另外 AboutDialog 也有个 companyLogo
属性,虽然我没试但是这个或许你能用。我觉得你可以考虑...
- 试试 AboutDialog 的 companyLogo 属性
- 干脆自己提供个对话框,里面爱放啥放啥,爱咋放咋放(
我想加个可以放图片的放一下星火吉祥物
顺带羡慕一下有吉祥物。目前这个项目连个 logo 都没有,目前是直接用了 distrobox 附带的图标((
除非你想一边搓dtk一边做,否则没必要,用户不差这一个依赖
还没看星火商店的代码,你们是有用 kirigami 吗?主要问题在于不太清楚 kirigami 应用在 Chameleon 主题下会不会很惨,所以也不太敢用。即便是目前保持尽可能用 Qt QuickControls 2 自带控件的情况都发现了一些问题,比如 GroupBox 标签背景永远是白色的,这个问题我搓 distro-rack 的时候才发现,这个 dtk6declarative 的问题我今天才修掉。
还要考虑下其他distro的用户可能也喜欢这个,毕竟做得很好,所以引入kde依赖没什么,反而是最新的dtk可能会带来麻烦
这个反而是事先就考虑到的了。目前 DDE 相关的样式是完全运行时的 QML import,并且是根据 XDG_CURRENT_DESKTOP
环境变量决定是否使用 DDE 样式的。对于非 DDE 环境下,完全不会尝试 import,外观则目前会用一个很朴素的通用样式(因为只用到了 QQC2 的组件),目前是这个样子:
玲珑可以用 host-spawn
喔,原来玲珑有啊,那看来是可行的了。回头瞅瞅看。
确实认同这个观点,不过商店目前应该没有提供“在distrobox中安装软件”这种性质上的功能,恐怕商店也没这个计划...吧。
加到星火里(不是)
之前DCM时代有指示dpkg操作distrobox安装软件包的套娃操作(虽然比较草但是确实可用),可以考虑一下这样能够上架
不过如果不想和官方绑定太深的话还是想想别的办法吧
顺带羡慕一下有吉祥物。目前这个项目连个 logo 都没有,目前是直接用了 distrobox 附带的图标((
没事有小浣熊()
星小火展示页很久没有人写了(
还没看星火商店的代码,你们是有用 kirigami 吗?
没有,星火只有dtk5 widget。这部分单纯是讲没有必要单纯为了减少依赖数量而不使用相关技术,能用就用就好,但是如果有其他考量那就再讨论。
对于非 DDE 环境下,完全不会尝试 import,外观则目前会用一个很朴素的通用样式
感觉过于朴素了,也许可以试着移植deepin下的外观而不是阉割效果?
加到星火里(不是)
加加加,星火加了我就肯定不加了。想法是接packagekit管理容器内的软件包,但我自己本身是没这个需求的,所以暂时也没什么意向做这个。
没事有小浣熊(
小浣熊是 deepin 的吉祥物,这个项目严格来说(至少现在)不是 deepin 的产品。不过目前的关注度而言,感觉也用不着折腾logo什么的(
星火只有dtk5 widget。这部分单纯是讲没有必要单纯为了减少依赖数量而不使用相关技术,能用就用就好,但是如果有其他考量那就再讨论。
建议考虑迁到 6 吧,或者至少支持选择性的 Qt 5/6 构建,免得目标发行版哪天 drop qt5。
感觉过于朴素了,也许可以试着移植deepin下的外观而不是阉割效果?
单纯因为 deepin 下的裸 QQC2 效果比较惨吧,换 breeze 估计还是会相对能看一些的。(回头有空在 KDE 环境里试下 edit: 试了下,确实也不太能看...不过我倒是确实有计划让它至少在 KDE 下能看来着。下面附个现状图)
不过反正目前状态本来也没折腾外观就是了(x
加到星火里(不是)
加加加,星火加了我就肯定不加了。想法是接packagekit管理容器内的软件包,但我自己本身是没这个需求的,所以暂时也没什么意向做这个。
没事有小浣熊(
小浣熊是 deepin 的吉祥物,这个项目严格来说(至少现在)不是 deepin 的产品。不过目前的关注度而言,感觉也用不着折腾logo什么的(
星火只有dtk5 widget。这部分单纯是讲没有必要单纯为了减少依赖数量而不使用相关技术,能用就用就好,但是如果有其他考量那就再讨论。
建议考虑迁到 6 吧,或者至少支持选择性的 Qt 5/6 构建,免得目标发行版哪天 drop qt5。
感觉过于朴素了,也许可以试着移植deepin下的外观而不是阉割效果?
单纯因为 deepin 下的裸 QQC2 效果比较惨吧,换 breeze 估计还是会相对能看一些的。(回头有空在 KDE 环境里试下 edit: 试了下,确实也不太能看...不过我倒是确实有计划让它至少在 KDE 下能看来着。下面附个现状图)
不过反正目前状态本来也没折腾外观就是了(x
建议考虑迁到 6 吧,或者至少支持选择性的 Qt 5/6 构建,免得目标发行版哪天 drop qt5。
这个目前双线并行
祝Blumia佬编码顺利捏
睡了睡了
Popular Events
More
deepin 做“根社区”以来,在我的视角下,很多时候困扰用户的一个问题是,适用于其他发行版生态的应用没很好的办法在 deepin 环境上使用。很多初入 linux 世界的新手大概率会盲目顺着百度搜来的结果在 sourceslist 里加源,只为安装自己想用的某个/些特定的软件,但不知道混源其实是很大的风险。deepin 25 引入了磐石不可变,使用户不再能很轻松的修改 sourcelist,但想必很多用户的选择是,查找如何禁用不可变保护的方式并关闭不可变保护,以便于跟随网上找到的教程,而不是想更合适的解决办法到底是什么。
不知道大家还记不记得我老早之前发的一个帖子:使用 Distrobox 在 v23 轻松安装你想要的软件包 ,而这就是我发之前 distrobox 帖子的原因:告知大家一个更方便的使用适用于其他发行版软件包的方式。后来,商店也上架了一些 distrobox 容器软件包以供无法直接访问 dockerhub 的用户更方便的创建容器,但显然这个帖子本身并不能解决一些易用性方面的问题:
后来,我注意到商店上架过一个叫 DistroGUI 的应用,声称是 distrobox 的图形化客户端,但下载后发现这个应用已经不可用了。搜索一番后发现了 DistroShelf 是个不错的替代品,然后给它提交了一些 PR 来增加 DDE 相关的支持(比如支持调起深度终端),但这个应用的推荐获取途径是 flatpak/flathub,于是就在考虑是否能打个原始 deb 包以供不太方便访问 flathub 的用户使用。就在尝试看是否能将其直接打包在 deepin 25 环境时,发现它依赖了蛮高版本的 gtk4-sys,并且 deepin 一时半会儿大概是无法升级所提供的相应软件包,于是这条路也不太通了。
于是剩下了一个蛮粗暴的方案:造轮子。刚巧最近也在研究一个差不多性质上是“现如今,各式各样的LLM能多大程度上帮助软件开发者完成任务”的主题内容,考虑到这个想法不算特别复杂,就打算拿这个想法试下水,基于 Qt 6/QML 造一个 distrobox GUI 的轮子,提供这些功能:
目前,这个轮子其实有了蛮不错的进展:预期的功能除了外观没有打磨外,基本功能已经齐全且可用了,用户可以在界面上比较直观的对 distrobox 容器进行相关操作,不再需要记住和输入复杂命令。(下面的截图是 9/4 更新过的,比之前刚发帖子的时候的状态稍微好了一点)
目前,感兴趣的用户可以在 GitHub 获取到完整源码以及 GitHub Action 构建的 CI 版本: https://github.com/BLumia/distro-rack
不过,尽管我知道有很多地方是可以打磨的,但我并不知道这个项目会有多少人实质上真的感兴趣,所以暂时不清楚后续是否应当对这个项目投入精力进行打磨。我想知道的是这些内容:
所以,非常欢迎你在帖子下面回复下你的看法!
(ps. 写完点发布之前,发现我写的这帖子内容有一股 “AI 味”,不过这帖子的内容确实是完全手写的来着
)
(pps. 这个软件不是 deepin 官方提供的解决方案,是纯粹个人作品)
Update (9/1 12:50): Gitee 目前也有仓库源码镜像了,只不过 CI 版本的下载肯定是暂时没有的: https://gitee.com/blumia/distro-rack
Update (9/3 23:35): 现在可以在 Gitee 和 GitHub 下载编译好的版本了,后续见:https://bbs.deepin.org.cn/post/291256
Update (9/4): 发了个新帖子但发现新帖子好像没人看,不知道是不是因为标题太像了,所以干脆也更新到这个帖子里得了。
根据目前收到的反馈,现在源码和二进制(预编译版本)都在 GitHub 和 Gitee 两个位置提供,以便各位按自己的网络情况自行取用。
目前而言,基本功能是可用状态了,UI 目前做到在 DDE 和 KDE 下都有初步比较说得过去的状态。
新帖子在:https://bbs.deepin.org.cn/post/291256