“Wayland 毁掉一切!gist.github.com”有些人已经看过了这篇 Probonopd 批评 Wayland 的略有名气的文章。Probonopd 是 AppImage 开发者的核心者之一,他批评 Wayland 并非 X11 的直接替代品。他在 GitHub 上创建了一个 新的仓库github.com,再次吸引了公众的目光,他希望为目前 Wayland 原生应用无法使用的功能创建协议。而这些功能是 Wayland 标准协议有意缺失的,但缺乏标准化意味着它们无法成为应用开发者可信赖的平台组成部分。
尽管开发者圈子里有人对此一笑置之,乃至嘲笑,但对于普通人来说,“Wayland 毁掉一切!”这句指责可能戳中要害,或者至少看起来有几分道理。因为从某种角度,Probonopd 是对的:Wayland 确实破坏了所有直接依赖 X11 功能的事物!
只是这种角度是错误的。
试想,如果我说:“Linux 让 Photoshop 无法工作,你还是应该坚持使用 Windows!”你该如何回应呢?你可能会说:“等等,问题的关键是 Photoshop 不支持 Linux!”你说得对,这是一个微妙且重要的区别,它将责任放在了正确的位置。因为即使是 Linux,也无法“不破坏” Photoshop;相反,Adobe 需要为其产品进行移植,只不过他们还没有做罢了。
对于 X11 和 Wayland,情况也同样适用。Wayland 并不是为了取代 X11 而设计的,就像 Linux 不是为了取代 Windows 而设计的一样。当我们从一个操作系统转到另一个时,有必要调整我们的期望,认清可能需要的改变。
尽管 Wayland 并非设计为 X11 的直接替代品,但它最终肯定会取代 X11。但这意味着它从一开始就打算比 X11 做得更少,而这是正确的。
X11 是个糟糕的平台
在那些古老的日子里,X11 是个完整的开发平台。以 X11 为目标的应用程序可以使用 X11,通过内建的小部件工具包来进行 UI 绘制;借助自带的打印服务器打印文件;进行屏幕录屏;设定全局快捷键等等。这一切都远在我接触技术之前,但我感觉到,X11 要么是在最初就被设定为面向应用开发者的开发平台,要么在早期阶段迅速演变成了这样一个平台。
然而,情况并没有如预期那样发展。即使是以当时的标准而言,其内置的 UI 工具包看起来也很丑陋。那些请求同一资源的应用可能会互相冲突,破坏彼此的功能,除非卸载其中一个应用程序,否则根本无法修复。像打印这样的特性渐渐没落,因为将这样的功能放在窗口管理器里就是个错误,而后续的维护者也缺少必要的专业知识或兴趣去维护它。诸如此类,不一而足。
像 Qt 和 GTK 这样的 UI 工具包迅速崛起,以更适合用户和便于应用开发者定位的方式,接管了大多数此类应用平台程序的中间件职能。我们这里说的是九十年代中期,那已是相当久远的时代了。
(当然,这样说可能有些不公平;人们抱怨 Wayland 缺少的其实并不是打印服务器。实际上,更多的是关于应用能否设置自定义窗口图标,以及移动自身的窗口。这些都是非常困难的情况;Wayland 上没有这些功能,理由就是这些功能在 X11 中被滥用,导致了难以解决的问题。要将这些功能移植到 Wayland 并非易事,涉及很多的权衡决定。)
Linux 并非一个平台
然而,UI 工具包的兴起无疑导致了应用程序的格局变得支离破碎。现在,FOSS 应用程序开发者不再为一个目标(X11)进行开发,而是为 Qt、GTK 或其他工具进行开发,从而我们看到了了大量的“KDE 应用” 和 “GNOME 应用”。是的,这些应用可能在其他平台里也能运行,但很明显,它们是在哪个平台和工具包上开发的,在哪个平台和工具包上运行效果最好。在其他平台运行时,它们可能看起来感觉很奇怪,或者某些功能可能不好用或根本无法使用。
这就是我们今天的现状。没有人会专门去编写一个 “X11 应用”;他们的应用可能会采用 X11 的某些特性,但这只是因为没有更好的替代方案,而实际上,在应用的 99.9% 的功能实现中,他们会选择 Qt、GTK、KDE Frameworks 或者其他相似工具。
这给我们带来了一个潜在的棘手问题:Linux 也不是一个真正的平台,在成为一个平台方面它并不比 X11 更成功。因为几乎没人会专门编写一个“Linux 应用”;直接调用原始的 Linux 内核系统通常是没必要的,因为无论你使用的是什么 UI 工具包,都会封装这些功能,并且将其抽象到工具包所支持的所有各种平台上。这样一来,工具包就能确保这些功能在 Linux 平台也都能顺利工作。
真正的平台
那么,对于跨桌面的互操作性而言,所有希望都已经破灭了吗?不,实际上现在的前景比以往任何时候都要美好!因为如今事实上出现了一个新兴的平台;如果你需要,它可以将各种应用工具包都抽象化。我说的是 Portals、PipeWire,以及 Wayland 协议。
Probonopd 认为这些都是附加组件,不应该在系统上运行,但我认为他的这种观点并不站得住脚。提供全面功能的单体窗口服务器模式在几十年前就被证明是失败的。取而代之的是库和 API,每个 FOSS 开发者都可以合理预期在现代系统运行这些。
门户系统提供了一种标准化的方法,用于展示平台原生的打开或保存对话框、发送通知、以其他应用打开文档、打印文档、拍摄截图、录制屏幕、处理拖放操作、查看用户当前主题是亮色还是暗色,等等。在很多功能的实现上,门户系统都倚赖于 PipeWire,因此你可以预期 PipeWire 也会被安装。同时,你也可以期待大部分 Wayland 合成器 — 尤其是两个最重要的合成器 KWin 和 Mutter — 支持几乎所有公开标准化的 Wayland 协议。
我认为这就是平台:Portals + Wayland + PipeWire。很明显,并没有一个好记的名字来囊括这一切。🙂 或许我们可以叫它 PW^2^。不过,如果你的应用程序以这些平台为目标,那么它几乎可以在所有现代 Linux 系统上运行。并且,Qt 和 GTK 这两个大型的 FOSS 工具包都为此提供了全面的支持。所以,使用你喜欢的任何 UI 工具包都可。
为何是现在?
我们最近听到越来越多关于这个话题的讨论,因为这个转型正在加速发展。X11 的维护者已经宣布终止对其的维护,而 Plasma 则开始默认采用 Wayland,GNOME 也是如此。Fedora 甚至完全放弃了对 X11 的支持。
我们现在正处于这样一个阶段,那些以前从未考虑过这个问题的人开始思考,并意识到他们的特定使用场景所需的所有组件都还没有到位。可这其实是好事!他们的意见被听取了,变化就有可能发生。我希望这一切能早点发生,但我们也要承认现实,我们还在路上,最近围绕远程控制、色彩管理、绘图板以及窗口布局等方面的提案和工作非常频繁。可能会有一个尴尬的阶段在等我们,直到所有需要的部分都到位。对于那些由于关键遗漏而备受困扰的人,我建议他们继续使用 X11,直至问题解决。没人会去阻止你(嗯,除了 Fedora,所以如果你确实无法适应,那就不要用 Fedora 🙂)。探索新事物应该是充满乐趣的,如果不是这样,那就转换一个角度再尝试吧。
结语
在这个语境下,“毁掉一切”或许可以更准确地表达为“还没完全移植所有事物”。这种移植是必要的,因为 Wayland 设计的目标聚焦于未来,而未来并不完全兼容我们过去所做的一切,因为事实证明,其中很多东西已经没有意义了。对于那些有意义的东西,我们已经提供了一个兼容层(XWayland),同时,任何需要深度系统集成的部分,一般都有一个解决的路径(如 Portal、Wayland 协议以及 PipeWire)或者正在积极的研发中。整个世界,都在发生变化!
在抛弃 Xorg 之前,请三思。Wayland 会毁掉一切! | Linux 中国
原创 邀你一起加入 Linux中国 2023-12-31 20:29 发表于海南
**导读:**LCTT 译注:之前翻译发布的《Wayland 真的毁掉一切了吗?》引来了很多讨论,为了使讨论更全面,我也将该文所反驳的原文也翻译过来,供大家参考。
本文字数:3844,阅读时长大约:5分钟
https://linux.cn/article-16520-1.html
作者:Probonopd
译者:ChatGPT
如果你希望现有的应用程序能够“顺利运行”,而不需要做调整,那么你可能更愿意避免使用 Wayland。
Wayland 并没有解决我遇到的问题,但却破坏了我几乎需要的一切。甚至是最基本、最简单的事情(如
xkill
) - 在这种情况下没有明显的替代品。通常,它会保持破坏的状态,因为 Wayland 的人员似乎主要关心的是 Automotive、Gnome,也许还有 KDE - 并在此过程中忽视了其他人,比如那些只使用 X11 窗口管理器或 GNUstep 的人。Wayland 的支持者们让人们觉得 Wayland 是 Xorg 的“继任者”,但事实上并非如此。它只是一个不兼容的替代品,并且甚至没有(也不打算)具有对等的功能(存在 功能缺失github.com)。不像 X11(X 窗口系统),Wayland 协议设计者们积极避开“窗口”的概念,而是编造出让人无法理解的词语,如 “xdg_toplevelwayland.app”。
不要使用 Wayland 会话! 不要让 Wayland 毁掉一切,然后让其他人修复它造成的破坏。或者强制让每个人更多地使用红帽或 Gnome 组件(glib、Portals、Pipewire)!
Wayland 似乎是由那些对已有软件毫不关心的人创造出来的。他们以为每个人都乐于重写所有东西,或者只使用 Linux 上的 Gnome(而不是,NetBSD 上与 ROX Filer 搭配使用的 twm 之类)。
补充:当我写下上述内容时,我并没有真正意识到 Wayland 究竟是什么,我只是注意到一些发行版(如 Fedora)开始推送它给我,并在我开始使用后发现了一些问题。现在我明白了实际上你不能“安装 Wayland”,因为与 Xorg 不同,并没有一个“Wayland 显示服务器”,每个桌面环境都有自己的“显示服务器”。也许 “Wayland 的开发者们” 关心的并不只是 Gnome,但任何在 Gnome 的 Wayland 实现中的修复并不能自动地惠及所有的 Wayland 软件用户,也许他们也不会推荐这种实现。
2023 年 12 月再次补充:如果有什么东西想要替代桌面电脑(比如专业 Unix 工作站)的 X11,那么它最好支持用于那种场景的所有需要的功能(以及关键概念,如窗口)。那些人们的冰箱上也有显示器在这种讨论,在此并不重要。我们需要提出 缺失的 Wayland 协议github.com 以实现与 X11 的全面功能一致性。
Wayland 的设计本身就存在问题
◈ 一旦窗口管理器出现崩溃,所有正在运行的应用程序都将被迫停止。
◈ 你无法以 root 用户的身份运行应用程序
◈ 设计上的限制使你无法执行在 Xorg 中可以实现的众多功能
◈ 没有一个被所有人所使用,且与桌面环境无关的
/usr/bin/wayland
显示服务器应用程序(这与 Xorg 不同)◈ 它将大量的工作都推给了窗口管理器。结果就是,在不同的窗口管理器中,相同的基础功能可能会有不同的实现方式,存在不同的表现和问题——也就是说,那些在桌面环境 A 中正常运行的可能在桌面环境 B 中并不适用(例如,你经常会听到有人说某个功能 “在 Wayland 上能正常工作”,但是实际上它只能在 Gnome 和 KDE 上正常运行,而不能在所有的 Wayland 实现上运行)。这个问题在以下的链接中得到了很好的总结:https://gitlab.freedesktop.org/wayland/wayland/-/issues/233 。
Wayland 造成破坏的情况
下面列出了许多这种破坏情况,译者不打算详细列出细节(可在原文处查看)。这些人们补充的 Wayland 造成破坏的情况有:
◈ Wayland 影响了屏幕录制应用的正常运行
◈ Wayland 影响了屏幕共享应用的正常运行
◈ Wayland 影响了自动化软件的正常运行
◈ Wayland 影响了 Gnome-Global-AppMenu(Gnome 的全局菜单)的正常运行
◈ Wayland 破坏了与 KDE platformplugin 的全局菜单链接
◈ Wayland 影响了与非 KDE Qt platformplugins 的全局菜单正常运行
◈ Wayland 影响了那些没有提供特殊 Wayland Qt 插件的 AppImage 的运行
◈ Wayland 影响了 Redshift 的正常运行
◈ Wayland 影响了全局快捷键的正常使用
◈ Xfce 在 Wayland 下可能无法正常工作?
◈ Wayland 在英伟达硬件上可能无法正常工作?
◈ Wayland 在英特尔硬件上表现异常
◈ Wayland 偏向 Linux,影响了 BSD 的正常运行
◈ Wayland 复杂化了服务器端窗口装饰的处理
◈ Wayland 影响了窗口自我提升 / 激活的功能
◈ Wayland 影响了 RescueTime 的正常工作
◈ Wayland 影响了窗口管理器的正常运行
◈ Wayland 需要 JWM、TWM、XDM、IceWM 等重新实现类似 Xorg 的功能
◈ Wayland 影响了 _NET_WM_STATE_SKIP_TASKBAR 协议的正常使用
◈ Wayland 影响了 NoMachine NX 的正常运行
◈ Wayland 影响了 xclip 的正常使用
◈ Wayland 影响了 SUDO_ASKPASS 的正常工作
◈ Wayland 影响了 X11 atoms 的正常使用
◈ Wayland 影响了游戏的正常运行
◈ Wayland 影响了 xdotool 的正常使用
◈ Wayland 影响了 xkill 的正常工作
◈ Wayland 影响了屏保的正常显示
◈ Wayland 影响了窗口位置设置的准确性
◈ Wayland 影响了色彩管理的正确性
◈ Wayland 影响了 DRM 租赁的正常流程
◈ Wayland 影响了家庭内流媒体的正常播放
◈ Wayland 影响了 NetWM 的正常工作
◈ Wayland 影响了窗口图标的正常显示
◈ Wayland 影响了拖放功能的正常使用
解决方法
对于用户:可以避免使用 Wayland 会话,或者卸载那些只提供 Wayland 会话的桌面环境或 Linux 分发版。同时,也可以尽量避免使用只适用于 Wayland 的应用,比如 PreSonus Studio Onesupport.presonus.com(可能的解决策略:在 https://github.com/cage-kiosk/cage 中运行此类应用)。
对于应用开发者:可以采取措施强制在 X11/Xwayland 上运行应用程序,就像 2023 年 11 月的 LibrePCB 所做的一样。
强制用户习惯 Wayland 的实例
这种情况正是本文想要警告和避免的。
◈ Asahi Linux 对 ARM 架构的 Mac 强制使用 Wayland,详情参见: https://social.treehouse.systems/@marcan/110354541574112092
◈ Fedora 对 KDE Plasma 强制使用 Wayland,详情参见:https://fedoraproject.org/wiki/Changes/KDE_Plasma_6#Why_drop_the_X11_session_with_the_Plasma_6_upgrade?
◈ 红帽对 RHEL 强制使用 Wayland,详情参见:https://www.redhat.com/de/blog/rhel-10-plans-wayland-and-xorg-server
参考资料
◈ Dudemanguy's Musings:Wayland 无法挽救 Linux 桌面dudemanguy.github.io
◈ Chris Titus Tech:Wayland 对比 Xorg https://www.youtube.com/watch?v=U_MBJcD3SFI
◈ tildearrow:有人说 “反 Wayland 无稽之谈” 吗?tildearrow.org
◈ pcsx2:CI/Linux:禁用 Wayland 并进行“春天大扫除”github.com
(题图:DA/fbfad36b-baba-4237-aceb-c86b99ef379b)
via: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
作者:Probonopd 译者:ChatGPT 校对:wxy
欢迎遵照 CC-BY-SA 协议规定转载,
如需转载,请在文章下留言 “转载:公众号名称”,
我们将为您添加白名单,授权“转载文章时可以修改”。
转载 Linux中国 公众号