Why I Can’t Feel Like Wayland

Peek is a simple animated GIF screen recorder:

Just open up Peek, resize the window and you will have that portion of your screen captured nicely into a .GIF. It is really neat for tiny demonstrations or bug reporting. To be honest, it is the one thing I missed most under Wayland. And, no, it can’t be ported to Wayland:

The big issue is the second goal (“experiment if it would be doable to implement the single window user interface Peek provides using standard Gtk3 widgets”) and how Peek fails it. While I am happy the UI worked as it did, there are too many technical challenges with it that I think Peek’s UI has no future. Many of these have to do with how Wayland changed the way applications are being handled.

– ANNOUNCEMENT: Deprecating the Peek project

There are a few alternatives like Kooha, most of which seem to use xdg-desktop-portal for screen cast data. But, just look at this troubleshooting page: it’s nowhere near an out-of-the-box experience (unless you are using GNOME/KDE).

Anyways, I did give Kooha a try before jumping into Wayland, only to find that it (along with xdg-desktop-portal (ScreenCast)) doesn’t work under any X11 DE other than GNOME/KDE, which I didn’t realize until I dug into xdg-desktop-portal configurations.

Now let’s talk about a “Wayland feature” bug. I use an IME to input Chinese and Japanese, and the input candidate window flickers under Wayland:

This is mainly due to the whole poor state of wayland input method. The existing wayland input method protocol is not widely supported by compositor. Even though fcitx 5 support those protocols, the poor support in application and compositor make them not usable. Not to mention certain design flaw within the protocol.

In order to make input method some what usable with CURRENTLY available and widely adopted techniques, Fcitx 5 implements a mechanism called “Client Side Input Panel”, which basically asks client application to render the input window. This is done through dbus and IM Module for Gtk/Qt. The implementation requires using a underlying wayland protocol xdg_popup to show the window. Unfortunately, only new version of xdg_popup protocol supports moving a visible popup window, and this part is NOT implemented in Gtk3 and Qt5. What makes it even worse is that Gtk3 and Qt5 both comes to their end of life, which means it is not possible to get this new protocol support in Gtk3/Qt5. The issue is that input method requires to display a window that resizes and moves extremely frequently. To mitigate this issue, Fcitx 5 IM Module implement a hack that when we need to move the window, it will hide the window first and then show the window. Unfortunately, this would cause certain-level of blinking. It might looks bad in certain hardware and compositor combination.

– FAQ - Fcitx

Actually, Wayland has two input method protocols: an unstable (read: legacy) input_method_v1 that seems only implemented by Weston, an experimental input_method_v2, as is used by Fcitx, the IME I use. I guess it’s fair: it’s experimental after all! It’s only sixteen years since the initial release of Wayland and of course I can wait until input_method_vN gets into staging/stable phase and all applications move onto GTK4/Qt6. /s

Some applications can behave weirdly when used under Wayland. Suppose you have a window flickering like crazy, what do you do? Here is my three options:

1. Report it as a bug to application developers (and sometimes get forwarded to GTK/Qt/…);
2. Report it as a bug to compositor (like Sway) developers (and sometimes get forwarded to wlroots);
3. Maybe it is just a Wayland feature? 🤔

I am not saying these things don’t happen under X11: an anomaly in an X11 app could come from GTK or Qt or X11. But since Wayland does limit what an app window can do, these bugs (or features?) do appear quite often.

Actually, it seems to me that Wayland protocols are asking compositors to roll their own X11 server + compositor + window manager equivalence. So instead of:

• X11 server + (KWin/i3/Openbox/…) + (xcompmgr/picom/…)

You get:

• GNOME: Wayland protocol server + compositor + WM capabilities
• KDE: Wayland protocol server + compositor + WM capabilities
• Sway: Wayland protocol server + compositor + WM capabilities

And there’s more! You have xdg-desktop-portal-gtk and xdg-desktop-portal-kde and xdg-desktop-portal-wlr… And xdg-desktop-portal could work under X11, as long as anyone takes the time to implement an xdg-desktop-portal-x11 library.

And, actually you can implement your own X server and have:

• (X.org server/your X server) + (KWin/i3/Openbox/…) + (xcompmgr/picom/…)

But, you see, GNOME/KDE/Sway under Wayland has to implement their X server equivalent in the compositor, while under X11 we can always compose those components and make our own configuration. And that’t probably why most of the “indie” Wayland compositors now use wlroots.

So I also have niche keyboard setup: Colemak DH + swapped escape/capslock keys. Under X.org, you configure it with /etc/X11/xorg.conf.d/00-keyboard.conf; in Sway, you put the config in the Sway config with an input * block; and Gnome, KDE and maybe Hyprland all use their own configurations. I guess it’s what happens when you ask everyone to their X11 server. Even wlroots can’t help here.

The same applies to monitor configurations and others. And I see some desktop environments like LXQt struggle to support them all.

• Sway does not support window icons yet.
• Pop-up menus of LxQT panels are sometimes wrongly positioned.
• Blurry Xwayland applications under HiDPI.

But I guess I will still try out Wayland from time to time, because:

• I like privacy;
• wayvnc is good;
• multi-monitor support is good.

It’s just I will need to double triple-think before doing so. =-(