https://www.bilibili.com/video/BV1MmFQzGE7i/

手刹不就是纯 GTK 4

虽然不是不能做

当然，我就只是把adwaita当皮肤用了

主要不用adwaita的话，gtk4多数有点。。简朴

GTK 搞 libadwaita，Qt 搞 QML，我们都有美好的未来.jpg（

永永远远的坏起来啦！

* 现在libhandy没了（并入gnome变成libadwaita

现在libhandy没了

原先libhandy是中立的

> <@kimiblock:kimiblock.top> 不用 libadwaita 控件少来着 是的，在这个生态位上和libadwaita竞争的只有granite

不用 libadwaita 控件少来着

理论上可以不依赖libadwaita写Gtk4，但现在libadwaita都快成事实标准了

这真的很烦人

但是Gtk程序给我塞个12px超大圆角+不拿gnome portal喂就不可移动的窗口三大键

我能接受应用程序内部设计与外界不一致

CSD配合libdecor倒也不是不行

？

豪杰超级解霸（

鉴于 gnome 抱着 csd 不放，就算不是也是了

gnome 啊

到底是谁发明的 CSD 我请问了

marine 创建了新帖 尝试平铺桌面第一次 感觉良好 - https://forum.archlinuxcn.org/t/topic/15954/1

逆天

不知道为什么设置是在用户设置里头

[m.image] https://github.com/settings/copilot/coding_agent

[m.image] Pasted image.png

mutter: f nv

mutter 新的 frame scheduling 在 NVIDIA 上会卡卡的

niri不卡（

[m.image] Pasted image.png

来kde吧，kde不卡（

草

[m.image] image.png

noctalia的workspace怎么老是无法更新，难道是因为suspend

没见过

输入文字之后这个候选框会自己在压缩

[m.image] * 为什么xwayland-satellite的fcitx候选框会这样，de是niri

[m.image] * 为什么xwayland-satellite的fcitx候选框会这样

[m.image] 为什么xwayland下的fcitx候选框会这样

[m.image] 千呼万唤始出来

终于

[m.image] 4254231D-3DD0-4984-932E-F7547EBA53D4.jpeg

* 就portal本身是x-d-p提供接口然后另一个程序提供实现这个画风也很怪，可能是为了能够让某些接口走这个实现，另一些走那个实现？

~~另外就是x-d-p的实现居然是GObject based C-language，简直是魔鬼~~

就portal本身是x-d-p提供接口然后另一个程序提供实现这个画风也很怪，可能是为了能够让某些接口走这个实现，另一些走那个实现？ 讲真的也给人一种其实没太大必要的感觉，一开始要是没有这种后端部分替换的功能的话，会倒逼各个实现尽力实现完全的。

可能还是dbus特意设计成method call/return一来一回，底层上带有同步语义，有点过度设计了。 一般的协议是没有这种底层上的配对，call/return语义是应用层自己做的，就比较好实现异步的语义。 要是portal协议直接基于uds可能看起来画风就会正常一点。

哦，那我猜大概是因为 dbus 没有 Wayland 那样的 new_id 消息

就portal一般会返回一个字符串，拿这个字符串拼一个object path出来，然后靠这个request object来发response signal把结果带给调用者。 wayland的话，如果需要什么identifier来标识……某个request/response的话，一般设计成event带上request id让客户端知道这个是哪个request

Settings 找了一圈也没看到关闭的地方

[m.image] Pasted image.png

GitHub 又开始推销 Copilot 大份了

* 如果服务长期不响应method call，message bus应该发error吗？看了眼dbus spec好像没有提到这点？

* 如果服务长期不响应method call，dbus daemon会发error吗？看了眼dbus spec好像没有提到这点？

request object 是什么？我怀疑 Wayland 并不是没有类似的东西，只是不叫这个名字

dbus daemon发的error类型的消息吗？

因为会 timeout

讲道理我不太理解为什么portal要设计request object这个东西，wayland协议也是异步设计，就没有这种东西。

这个库还是挂在 API reference 上推荐的

要么是 go portal 的实现没有捕捉 response, 要么是 GNOME Portal 有问题

* ~~怎么感觉无限循环了~~ 我的意思是，微信本身是fork出一个xdg-open进程去打开文件还是怎么打开的文件。因为沙盒化之后内外路径不一致，portable微信似乎做了点处理让文件路径变得正确了。

* Request object的Response signal携带的参数可以说明失败吧，当然前提是portal确实返回了Request object, which does return a Response signal。 你所说的巨坑的portal是指哪个portal backend？ 你是发现Request object不发Response信号？

Request object的Response signal携带的参数可以说明失败吧，当然前提是portal确实返回了Request object, which does return a Response signal。 你是发现Request object不发Response信号？

怎么感觉循环了

有没有 Nftables 的上手指南)

spec 没明说, 但是这个 OpenURI 总不能是 long-running task 需要 watch Request object 的 response signal 吧

不返回错误这个决定是 portal 的实现做的，还是 xdg-desktop-portal 自身做的特殊处理？

现在不如把这里的 error check 删掉 🤡 https://github.com/Kraftland/portable/blob/master/lib%2Fopen-ng%2Fopen.go#L184

一开始我以为是 go openuri package 有问题, 后来抓了 Bus 发现就是没返回

* 我现在发现打开 symlink 是必失败, 好像 host 上只读的文件也会失败

我现在发现打开 symlink 是必失败, 好像 host 上只读的文件也失败

草，这样吗

这个 Portal 巨坑, 失败了也不返回东西

我其实也没遇到过，一开始是听说，后来看一些源码确认了这一点

当我意识到目前还没发生过混成器崩溃的时候，我猜不久就要遇到了）

已知mpv处于unmap状态(只有声音)也能幸存(

不过我得首先遇到一次崩溃才能知道这些了

原来如此

> <@telegram_824372155:nichi.co> 过拟合了。目前只有 Qt 能下 Wayland 合成器崩溃后幸存 🤔

* 过拟合了。目前只有 Qt 能在 Wayland 合成器崩溃后幸存

过拟合了。目前只有 Qt 能下 Wayland 合成器崩溃后幸存

> <@telegram_1066760420:nichi.co> 我就去个洗手间的功夫，回来屏幕前一看，clash verge + vivaldi + discord + element 都退出了，kde 也锁屏了（本来阻止了，也就是说它重启了） > 倒是 telegram 还在运行，谁崩了这么大威力 翻译一下，WebKitGTK+Chromium+Chromium+Chromium，所以已知这里大部分责任在chromium上

另外 xdg-open 脚本里针对 flatpak 的实现就是 gdbus 命令行调用 OpenURI

flatpak 有一个 xdg-open 命令的实现的

咱是猪，分不清 🙈

Qt支持重连的。说实话显示不了窗口就死掉的程序行为是很不正常的。

tg是qt

诶？那。。。tg 不是？

估计是chromium一卦的都会死（

会的，我以前kwin一死所有electron都死

刚在看 https://specifications.freedesktop.org/mime-apps/latest/ 我想知道各个portal impl的OpenURI是否遵守这个规范呢？

Wayland下，混成器死了，不支持重连的客户端都会死

但以前 kwin 好像不会带着其他的一起诶？

kwin（即答

我就去个洗手间的功夫，回来屏幕前一看，clash verge + vivaldi + discord + element 都退出了，kde 也锁屏了（本来阻止了，也就是说它重启了） 倒是 telegram 还在运行，谁崩了这么大威力

话说微信打开文件的逻辑是什么？直接调用xdg-open吗？

理论上还可以优化，因为现在只是找出一个包含变化区域的最大范围，还可以换成一个区域列表，这样对于两个变化的区域距离较远的时候效果会更好，但是我在思考有没有必要搞得如此复杂（

3

这玩意儿就应该默认关闭吧

[m.image] image.jpeg