我討厭為 Wayland 開發應用程式

背景

這篇文章探討了從開發者視角出發，在 Linux 環境下為 Wayland 顯示協定編寫圖形應用程式的痛苦經歷。作者對比了 X11 與 Wayland 的歷史背景，指出雖然 Wayland 被視為現代 Linux 桌面環境的未來，但在實際開發過程中，其物件導向協定的複雜性、繁瑣的初始化流程以及對簡單使用場景的忽視，讓底層開發變得極其困難。

社群觀點

針對作者對 Wayland 開發難度的控訴，Hacker News 社群呈現出兩極化的反應。部分開發者深有同感，認為 Wayland 的設計過於追求理論上的純粹與理想化，卻忽略了實踐中的易用性，甚至被批評為對開發者與使用者都不夠友善。這種「純粹性」導致了功能碎片化，由於 Wayland 核心協定過於精簡，許多功能必須依賴合成器（Compositor）自行實現，這不僅增加了開發負擔，也造成不同合成器之間行為不一致，進而加劇了 Linux 桌面環境的割裂感。

然而，另一派觀點則認為作者的痛苦源於「選錯了工具層級」。支持者指出，Wayland 本質上是一個底層通訊協定，而非高層級的圖形庫。在現代軟體開發中，直接操作 Win32 API 或 Xlib 同樣充滿挑戰，正確的做法應該是使用 GTK、Qt 或 SDL 等成熟的框架，由這些函式庫去處理底層的複雜邏輯。他們認為 Wayland 將安全性放在首位是正確的決策，雖然這限制了全域熱鍵、螢幕錄製或自動化腳本等功能的實現，但這能有效防止惡意軟體竊取剪貼簿或側錄鍵盤，是現代作業系統沙盒化趨勢下的必然選擇。

此外，社群中也出現了關於「安全性與靈活性」的辯論。反對者認為 Wayland 的安全限制過於死板，導致如 xdotool 這類強大的自動化工具難以重現，且目前的解決方案往往需要針對特定合成器編寫擴充功能，缺乏統一標準。儘管有人提到 wlroots 等工具能簡化開發，但整體而言，社群達成了一個共識：Wayland 確實提高了開發門檻，它將責任從顯示伺服器轉移到了合成器與應用程式開發者身上，這雖然帶來了更穩定的渲染與更好的安全性，卻也讓那些習慣於 X11 靈活性的老牌開發者感到無所適從。

延伸閱讀

在討論中，開發者們提到了一些實用的資源與替代方案。Wayland.app 提供了協定擴充功能的概覽，是開發時的重要參考。針對全域熱鍵與自動化需求，有人推薦關注 Hyprland 的全域快捷鍵協定。對於想要開發合成器的人，wlroots 被認為是目前最推薦的基礎庫。此外，留言中也提到了一段關於「解構合成器」的技術演講影片，深入探討了顯示架構的演進與問題。