> <@telegram_824372155:nichi.co> 没这回事 思考...

可能更多是移动平台失去了休眠能力，许多组件会因为休眠睡死，需要重新断电初始化才能恢复运作，而且这个睡死不是因为硬件驱动不良

O.O;

我才意识到，现代系统已经没有hibernation的能力了。所以刚刚移除了swap分区并启用了zram

不太符合arch一贯的实用主义哲学

神秘喵

原来如此） 刚刚找了半天

> <@telegram_5326856800:nichi.co> 输入法应该归 smithay 管理 思考.jpg

所以我没用

反正Wine Wayland还没脱离experimental阶段

bzd

> <@kimiblock:kimiblock.top> Portable 会继承 systemd 给的和用户手动在沙箱家里的变量 好哦

至少我觉得Wayland compositor一般不应该给所有进程都暴露input-method协议，毕竟那样就倒退回X11的安全机制了

或者是不是我没找到输入法相关的文档

niri是给所有进程都暴露input-method协议吗

我突然开始好奇

我应该说更符合预期的结果，也就是使用Wayland原生的text-input协议

* 应该只给XWayland程序设定IM_MODULE

应该只给XWayland程序设定IM_MODULES

IM Modules是X11的解决方案

Wayland下一般不用IM Modules会得到更好的结果

十分建议你别设定这堆IM_MODULE

以及

这类沙箱应该会屏蔽环境的吧

* 不熟bwrap，它会自动继承宿主的环境变量吗

不熟bwrap，它会自动继承宿主的环境变量

我的意思是ta在bottles里调整

> <@mahiro:ushio.uk> 如果是 flatpak 下载的 bottles，会不会需要用 flatseal 指定下环境变量？ 啊，Bottles可以给特定Bottle指定环境变量的

其实不影响你这里的使用

那就别给整个桌面环境指定这些*_IM_MODULE

不对，我应该先问你在用X11还是Wayland

以及如果是Wayland session不要给整个DE指定这些环境变量

你到底是ibus还是fcitx5

等等

内容如@im=fcitx，指向你目前的输入法

那你试试写下XMODIFIERS

> <@nyaacinth:mozilla.org> 网易云音乐在Windows上用个sandbox都会直接拒绝登录的 所以我建议放弃

网易云音乐在Windows上用个sandbox都会直接拒绝登录的

怎么说）

需要下载音乐的话用安卓客户端

我建议你用 https://music.163.com/st/webplayer

微信的新RCE，从PHP延续下来的优良传统（并非）之拼字符串+信任用户输入+不sanitize就直接执行

（似乎

可以只给特定类名开放blur

设置一下白名单

多窗口连续堆叠会卡出天际，即使其中大部分窗口没有用到blur

提示一下它存在性能问题

> <@telegram_7672225115:nichi.co> blur 搞好了 forceblur?

> <@telegram_217331471:nichi.co> 我有全局菜单 不需要 全局菜单好像在wayland还处于残废状态中

* 也有不一致的，有的专门把所有对话框的关闭按钮全部写死左边

而标准窗口写死右边

> <@telegram_7195205739:nichi.co> 你放右边基本就一致了 也有不一致的，有的专门把所有对话框的关闭按钮全部放左边

我左右都能接受，但重点是一定要一致

> <@telegram_7195205739:nichi.co> 关闭放左边更是💩 🫠

> <@nyaacinth:mozilla.org> 另外有些窗口需要等plasma6.6发布，它们作为Wayland程序实现了CSD但不绘制阴影，而kwin目前不支持强制装饰wayland窗口 plasma6.6提供了修复

另外有些窗口需要等plasma6.6发布，它们作为Wayland程序实现了CSD但不绘制阴影，而kwin目前不支持强制装饰wayland窗口

> <@telegram_7195205739:nichi.co> Kwin 窗口规则 + Klassy 窗口规则 不过这里有个问题，klassy和breeze窗口规则都只能匹配命中一个类名下的所有窗口，而不能匹配特定类型的窗口，有时遇到混用CSD和SSD的应用会意外隐藏一些不需要隐藏的标题栏

> <@telegram_217331471:nichi.co> 等什么时候支持关闭 csd 了再好吧） Gnome：你只要关闭CSD，你就失去窗口管理功能

晚安喵各位

OK，如果有出现纰漏，甚至是完全错误/莫名其妙(;´ヮ`)7 那说明我折腾论文AIGC查重已经折腾的神志不清了

（前文：我尝试重新拾起Gnome并光速败退） 在深入了解Gnome最近几年做的事之后，我觉得自己得到了这样的一个观点：它的问题某种意义上和React.js曾经的问题比较相似（这具体是不是个问题因人而异），都是有些过分的追求自身逻辑的一致性与哲学的完整实现。结果放弃接轨现实中的复杂多变的需求，所以现实生活中代替他们弥合这些接缝的变成了用户和外围开发者，保持这些“外围组件”与核心一致性/兼容性的工作也被抛给了用户，于是用户在类似的需求下会更容易得到一个易碎的环境。（与扩展、旧商业闭源软件亦或是生态外软件协同工作时，这些问题就会显现）