Wayland status?

[tinywrkb]

Any chance for a clear overview of Wayland's support in and for Fcitx5? maybe a blog post or a roadmap?

• Are there protocol extensions that Wayland is missing?
• What protocols are compositors and clients need to support?
• Does the candidate box suppose to work as a native Wayland client?
• Candidate box positioning?
• IIUC Wayland doesn't have _NET_WM_WINDOW_TYPE_DIALOG window type. Would this have a negative effect on the candidate box? specifically when using a tiling window compositor?
• Fcitx5 seems to work with some native Wayland clients, like Firefox, GTK3 based, and others. Can we expect some improvements with those apps in the future? like better candidate box positioning?
• Chrome with the Wayland Ozone backend doesn't seem to work at all with Fcitx5, this not even reported in the Keyboard and IME issues. It would be nice if a knowledgeable developer will point Google's devs in the right direction to solve this.

[wengxt]

This is a very complex topic.

1. Fcitx 5 already implemented all the existing input method protocol. There is no more work need to be done on fcitx side for all the existing protocol.
2. compositor need to support whatever protocol that fcitx supports, (zwp_input_method_*), as for between client and compositor, fcitx does not care.
3. Candidate box only works properly under two cases:

• client using wayland -> compositor -> fcitx to talk to fcitx, the candidate box positioning is done by the protocol.
• client using some traiditional dbus -> fcitx, but fcitx may use some way to position the window correctly, this is currently only possible for gnome-shell + kimpanel. If It's a xwayland client, actually it should work as good as under X11.

4. I dislike all the existing protocol because of lacking of capability comparing to the existing dbus/X11 ones, but I'm tired of having debating on such topic with current owner. Lack of ability of identifying different client in input-method-unstable-v2.xml swaywm/wlroots#2352 So my plan would try to draft my own one and make it to KDE to make it more generally usable.

[tinywrkb]

Thank you for the detailed reply!

• client using wayland -> compositor -> fcitx to talk to fcitx, the candidate box positioning is done by the protocol.

Do you have an example of a compositor and a client where it's working like this today?
I tried Alacritty running in Sway with input-method-unstable-v2 keyboard grab PR and while Fcitx5 successfully outputs characters, the candidate box wasn't visible.
With every other native Wayland client where the candidate box was displayed, the candidate box was running as an XWayland client, never as a native Wayland client (confirmed with xeyes).

When the candidate box will run as a Wayland client, I hope those of us who use a tiling window manager/compositor won't have trouble having it float.
This is completely broken in Firefox and Chrome/Chromium. The PiP windows don't float and need workarounds in Sway's config. The windows.WindowType popup doesn't float and there's no good way to work around this.

[wengxt]

because sway doesn't implement the input_panel part in the protocol, actually I don't know any compositor implement that. (weston has zwp_input_method_v1 support, but no one use that except a broken weston-editor demo use text-input-v1.) Someone told me he implemented that in kwin and showed me a screen shot, but I didn't check if it's mainlined maybe it's under review or sth.

Initially fcitx doesn't render anything at all if the input panel protocol is not available, because I think "what's point to workaround a broken one?" but people are asking me to render a X one as a fallback (#118), so I just add this support. Rendering a wayland one without input panel protocol is pointless because it can't do any positioning, using a X one at least it can do some "partial" position.

If you want anything works the best, use gnome. It doesn't use zwp_input_method, instead, it is using ibus's dbus to communicate with input method server and text-input-v3 with client. As for gnome shell, it has a benefit that it has extension and have all window information + ability to position window, so kimpanel as an extension can try to position it correctly (for wayland client, it's "current window" + "offset" mode, for X11 it's absolution position mode).

[wengxt]

Let me put this as a reference here: #207

[tinywrkb]

Thanks again!

So Gnome is in the best shape if using the Kimpanel extension.
Sway is missing zwp_input_panel_v1 so even though it has PRs for input-method-unstable-v2 keyboard grab and input_method_v2 popups it can't support the candidate box properly.

It would be great if this info will be put somewhere visible. Maybe as a table?

Compositor	Positioning	Native Wayland	Comments
Gnome/Mutter	Yes	Yes	Integration with the Kimpanel extension
KDE/KWin
Sway/wlroots	Not supported	No	Missing zwp_input_panel_v1 implementation

[wengxt]

input_method_v2

I think you misunderstood, input_method_v2 popup is the candidate box for zwp_input_method_v2

[wengxt]

zwp_input_method_v1 should be used with zwp_input_panel
zwp_input_method_v2 should be used with zwp_input_method_popup_surface

I didn't know about swaywm/sway#5890 when I looked at the last time, ideally with that sway may be able to show the window.

There's also an alternative solution: ask application to draw the popup window, which I listed #207.
uim and Windows is using this approach for a long time, but for the sake of UI consistency, I didn't take this approach, because for client for XIM and non-Gtk/Qt im module app, they still need to use server side UI. Also, being intrusive to application is very dangerous because of the existence of non-Standard Gtk/Qt application (e.g. firefox/libreoffice).

[yurenchen000]

on ubuntu 20 (wayland)

• in some app (gedit, terminator)
  fcitx has wrong popup position // on gnome3 they are ok.

• in some app (firefox)
  fcitx has right popup position

-----
I'm not sure where's the problem, wayland or fcitx

[SamLukeYes]

on ubuntu 20 (wayland)

* in some app (gedit, terminator)
  fcitx has wrong popup position // on gnome3 they are ok.

* in some app (firefox)
  fcitx has right popup position

---

I'm not sure where's the problem, wayland or fcitx

Gedit and GNOME Terminal are native Wayland applications in Wayland session, while Firefox runs in XWayland without some configuration. For better integration between GNOME and Fcitx, you can try this extension: https://extensions.gnome.org/extension/261/kimpanel/

[yurenchen000]

Gedit and GNOME Terminal are native Wayland applications in Wayland session, while Firefox runs in XWayland without some configuration. For better integration between GNOME and Fcitx, you can try this extension: https://extensions.gnome.org/extension/261/kimpanel/

👍 thanks a loooot, this sovle the problem.