未來會支援wayland嗎？

[jasonliang910304]

想嘗試hyperland但是目前似乎不支援wayland環境

[marktwtn]

開發能量不太足夠呢

[mingtsay]

HIME Wayland 支援可行性評估

此報告使用 Claude Code 模型 Opus 4.7 (1M context) 進行分析評估

1. 現有架構（X11）

HIME 目前有兩條輸入路徑，這對 Wayland 評估很關鍵：

路徑	機制	主要檔案
XIM 伺服器	daemon 內建完整 XIM server（IMdkit），透過 X11 ClientMessage 與舊式 app 溝通	src/IMdkit/lib/*、src/hime.c
HIME 自有協定	GTK/Qt IM module 透過 Unix socket / TCP 直接連 daemon，不走 XIM	src/im-client/hime-im-client.c、src/im-srv.c、src/gtk-im/、src/gtk3-im/、src/qt5-im/、src/qt6-im/

其餘 X11 相依點：

• 服務探索：client 透過 X11 root window 的 atom（HIME_ADDR_ATOM_*、HIME_SOCKPATH_ATOM_*）找到 daemon — src/im-addr.c、src/im-client/hime-im-client.c
• 候選／預編輯視窗：GTK 視窗，但用 XTranslateCoordinates + override_redirect 手動定位 — src/eve.c、src/win0.c、src/win1.c
• 假鍵送出：XTestFakeKeyEvent — src/eve.c
• 建置上 GTK 2 為預設，GTK 3 為選項；目前無 GTK 4 module

2. Wayland 的核心障礙

1. XIM 在原生 Wayland 不存在。 整套 IMdkit 對原生 Wayland app 完全失效。原生 app 改用 compositor 仲介的 text-input-unstable-v3，IME 端要實作 input-method-unstable-v2（zwp_input_method_v2）。

2. input-method-v2 支援度破碎。 wlroots 系（Sway / Hyprland / river）與 KDE Plasma 支援；GNOME / Mutter 完全不支援 —— GNOME 只認自己 in-process 的 IBus 整合。所以「Wayland 支援」天生只能是部分平台。

3. 候選視窗無法自行定位。 Wayland client 不能任意擺放 toplevel，也沒有 override-redirect。需改用 zwp_input_popup_surface_v2（跟著游標矩形）或 gtk-layer-shell。

4. XTestFakeKeyEvent 無法使用。 需改用 zwp_virtual_keyboard_v1，或對 input-method-v2 改走 commit_string 模型。

5. 服務探索不能靠 X11 atom。 需改用固定 socket 路徑（以 $WAYLAND_DISPLAY 命名）或環境變數。

3. 可行性結論

技術上可行，但工程量大 —— 等於在 XIM server 旁再寫一個 Wayland 後端。不過有兩點對 HIME 特別有利：

• 架構已經是 daemon + IPC 分離，輸入法引擎、字表、設定全部與顯示伺服器無關，不需更動。
• GTK / Qt IM module 走的是自有 Unix socket 協定，不是 X11 —— 它們在 Wayland 下本來就能跑，唯一卡點是「X11 atom 探索」與 Qt module 抓取 Display*。

4. 建議的分階段路線（依 CP 值排序）

階段 0 — XWayland（現況已部分可用）

目前 HIME 在 XWayland 下就能跑，服務 XWayland app 與原本的 XIM 路徑。許多發行版已這樣出貨。

階段 1 — 讓 client／探索脫離 X11（最高 CP 值）

改 hime-im-client.c、im-addr.c、Qt module 的探索邏輯：以 $WAYLAND_DISPLAY 命名固定 socket 路徑，取代 X11 atom。

這一步做完，所有 GTK / Qt app 在任何 compositor（含 GNOME）下，只要載入 HIME IM module 就能原生輸入 —— 完全不需要 compositor 的 protocol 支援。投資報酬率最高，風險與工程量都最低。

階段 2 — daemon 自身視窗 Wayland 化

候選／預編輯視窗改用 gtk-layer-shell 或 input-method popup surface，取代 eve.c 的 XTranslateCoordinates + override-redirect 定位。

階段 3 — zwp_input_method_v2 後端

給「不走 GTK / Qt module 的 app」（Electron、Firefox 原生 Wayland 等）使用。在 daemon 內新增 Wayland IME client，與 IMdkit 並存。僅 wlroots 系 + KDE 可用，GNOME 不行。

5. 整體建議

先做階段 1，用最小成本拿下絕大多數 GTK / Qt 桌面應用的原生 Wayland 輸入；階段 2、3 再視社群需求逐步補上。階段 1 不需碰 compositor 協定，是最安全的切入點。