In 1996, they came up with the X11 “SECURITY” extension:

https://www.reddit.com/r/linux/comments/4w548u/what_is_up_with_the_x11_security_extension/

This is what could have (eventually) solved the security issues that we’re currently seeing with X11. Those issues are cited as one of the reasons for switching to Wayland.

That extension never took off. The person on reddit wonders why – I think it’s simple: Containers and sandboxes weren’t a thing in 1996. It hardly mattered if X11 was “insecure”. If you could run an X11 client, you probably already had access to the machine and could just do all kinds of other nasty things.

Today, sandboxing is a thing. Today, this matters.

I’ve heard so many times that “X11 is beyond fixable, it’s hopeless.” I don’t believe that. I believe that these problems are solveable with X11 and some devs have said “yeah, we could have kept working on it”. It’s that people don’t want to do it:

Why not extend the X server?

Because for the first time we have a realistic chance of not having to do that.

https://wayland.freedesktop.org/faq.html

I’m not in a position to judge the devs. Maybe the X.Org code really is so bad that you want to run away, screaming in horror. I don’t know.

But all this was a choice. I don’t buy the argument that we never would have gotten rid of things like core fonts.

All the toolkits and programs had to be ported to Wayland. A huge, still unfinished effort. If that was an acceptable thing to do, then it would have been acceptable to make an “X12” that keeps all the good things about X11, remains compatible where feasible, eliminates the problems, and requires some clients to be adjusted. (You could have still made “X11X12” like “XWayland” for actual legacy programs.)

I wasn’t really aware until recently that programs can’t choose their own window’s position on Wayland. This is very weird to me, because this was not an issue on X11 to begin with: X11 programs can request a certain position and size, but the X11 WM ultimately decides if that request is being honored or not. And users can configure that.

But apparently, this whole thing is a heated debate in the Wayland world. 🤔

“Wayland Will Never Be Ready For Every X.Org User”

https://youtu.be/yURfsJDOw1E

@lyse@lyse.isobeef.org Oh, huh, maybe it was just my GNOME 2 themes back then that didn’t show the icon. 🤔

I like the looks of your window manager. That’s using Wayland, right?

Oh, no. It’s still X11. All my recent Wayland comments resulted from me trying to switch, but I think it’s still too early. Being unable to use QEMU (because it can’t capture the mouse pointer) is a pretty big blocker for me. This is completely broken, it just happens to be unnoticeable with modern guest OSes, so it’s probably not a priority for devs.

(Not to mention that I would have to fork and substantially extend dwl in order to “replicate” my X11 WM. And then, after having done that, I’d have to follow upstream Wayland development, for which I don’t have the resources. Things would need to slow down before I can do that.)

all that wasted space of the windows not making use of the full screen!!!1

Heh. I’ve been using tiling WMs for ~15 years now, so it’s actually kind of refreshing to see something different for a change. 😅

Probably close to the older Windowses.

That particular theme is a ripoff of OS/2 Warp 3: https://movq.de/v/6c2a948882/s.png 😅

We ran some similar brownish color scheme (don’t recall its name) on Win95 or Win98

Oh god. Yeah, I wasn’t a fan of those, either. 🥴

@movq@www.uninformativ.de According to this screenshot, KDE still shows good old application icons: https://upload.wikimedia.org/wikipedia/commons/9/94/KDE_Plasma_5.21_Breeze_Twilight_screenshot.png

And GNOME used to have them, too: https://upload.wikimedia.org/wikipedia/commons/9/9f/Gnome-2-22_%284%29.png

I like the looks of your window manager. That’s using Wayland, right? The only thing on this screenshot to critique is all that wasted space of the windows not making use of the full screen!!!1 At least the file browser. 8-)

This drives me nuts when my workmates share their screens. I really don’t get it how people can work like that. You can’t even read the whole line in the IDE or log viewer with all the expanded side bars. And then there’s 200 pixels on the left and another 300 pixels on the right where the desktop wallpaper shows. Gnaa! There’s the other extreme end when somebody shares their ultra wide screen and I just have a “regularish” 16:10 monitor and don’t see shit, because it’s resized way too tiny to fit my width. Good times. :-D

Sorry for going off on a tangent here. :-) Back to your WM: It has the right mix of being subtle and still similar to motif. Probably close to the older Windowses. My memory doesn’t serve me well, but I think they actually got it fairly good in my opinion. Your purple active window title looks killer. It just fits so well. This brown one (https://www.uninformativ.de/blog/postings/2025-07-22/0/leafpads.png) gives me also classic vibes. Awww. We ran some similar brownish color scheme (don’t recall its name) on Win95 or Win98 for some time on the family computer. I remember other people visting us not liking these colors. :-D

@movq@www.uninformativ.de Following all your Wayland endeavors, it doesn’t sound like a mature and usable thing to me yet.

Only figured this out yesterday:

pinentry, which is used to safely enter a password on Linux, has several frontends. There’s a GTK one, a Qt one, even an ncurses one, and so on.

GnuPG also uses pinentry. And you can configure your frontend of choice here in gpg-agent.conf.

But what happens when you don’t configure it? What’s the default?

Turns out, pinentry is a shellscript wrapper and it’s not even that long. Here it is in full:

#!/bin/bash

# Run user-defined and site-defined pre-exec hooks.
[[ -r "${XDG_CONFIG_HOME:-$HOME/.config}"/pinentry/preexec ]] && \
        . "${XDG_CONFIG_HOME:-$HOME/.config}"/pinentry/preexec
[[ -r /etc/pinentry/preexec ]] && . /etc/pinentry/preexec

# Guess preferred backend based on environment.
backends=(curses tty)
if [[ -n "$DISPLAY" || -n "$WAYLAND_DISPLAY" ]]; then
        case "$XDG_CURRENT_DESKTOP" in
        KDE|LXQT|LXQt)
                backends=(qt qt5 gnome3 gtk curses tty)
                ;;
        *)
                backends=(gnome3 gtk qt qt5 curses tty)
                ;;
        esac
fi

for backend in "${backends[@]}"
do
        lddout=$(ldd "/usr/bin/pinentry-$backend" 2>/dev/null) || continue
        [[ "$lddout" == *'not found'* ]] && continue
        exec "/usr/bin/pinentry-$backend" "$@"
done

exit 1

Preexec, okay, then some auto-detection to use a toolkit matching your desktop environment …

… and then it invokes ldd? To find out if all the required libraries are installed for the auto-detected frontend?

Oof. I was sitting here wondering why it would use pinentry-gtk on one machine and pinentry-gnome3 on another, when both machines had the exact same configs. Yeah, but different libraries were installed. One machine was missing gcr, which is needed for pinentry-gnome3, so that machine (and that one alone) spawned pinentry-gtk …

@movq@www.uninformativ.de LOL! No, I mean Wayland.

Since Wayland compositors handle input devices on a lower level than X11 window managers, every compositor has to figure out on their own what a “mouse wheel click” is:

• https://github.com/labwc/labwc/issues/1068
  
• https://github.com/labwc/labwc/pull/2933
  

(I think “Wayland compositor” is a misnomer. They are full-blown display servers that also do compositing, plus Wayland window management, plus X11 window management.)

One can only hope that all this eventually gets moved into the wlroots library. (I’m not sure if that’s possible, nor if people would want that.)

I give up.

Let’s try again next year. I don’t have the stamina. Death by a thousand paper cuts.

Can’t set up a meaningful taskbar: https://github.com/labwc/labwc/discussions/2924 (This is not a labwc issue, it’s a generic issue in the broader Wayland ecosystem.)

Thinking about doing “Wayland Wednesday”. Only use Wayland every Wednesday. Collect bugs, report bugs, fix bugs.

Something happened with the frame rate of terminal emulators lately. It looks like there’s a trend to run at a high framerate now? I’m not sure exactly. This can be seen in VTE-based terminals like my xiate or XTerm on Wayland. foot and st, on the other hand, are fine.

My shell prompt and cursor look like this:

$ █

When I keep Enter pressed, I expect to see several lines like so:

$
$
$
$
$
$
$ █

With the affected terminal emulators, the lines actually show up in the following sequence. First, we have the original line:

$ █

Pressing Enter yields this as the next frame:

$
█

And then eventually this:

$
$ █

In other words, you can see the cursor jumping around very quickly, all the time.

Another example: Vim actually shows which key you just pressed in the bottom right corner. Keeping j pressed to scroll through a file means I get to see a j flashing rapidly now.

(I have no idea yet, why exactly XTerm in X11 is fine but flickering in Wayland.)

The WM_CLASS Property is used on X11 to assign rules to certain windows, e.g. “this is a GIMP window, it should appear on workspace number 16.” It consists of two fields, name and class.

Wayland (or rather, the XDG shell protocol – core Wayland knows nothing about this) only has a single field called app_id.

When you run X11 programs under Wayland, you use XWayland, which is baked into most compositors. Then you have to deal with all three fields.

Some compositors map name to app_id, others map class to app_id, and even others directly expose the original name and class.

Apparently, there is no consensus.

… but you can’t set SDL_VIDEODRIVER=wayland globally, because that breaks Wine again …

… okay, the SDL backend works if you also set SDL_VIDEODRIVER=wayland.

@lyse@lyse.isobeef.org dmenu is a great example.

There have been several attempts at porting dmenu from X11 to Wayland. Well, not exactly “porting” it, more like rewriting it from scratch. Turns out: It’s not that easy.

dmenu is super fast and reliable. None of the Wayland rewrites are (at least none of the popular ones that I know of). They are either bloated and/or slow.

It takes a lot of discipline and restraint to write simple software and not blow up the codebase. This is much harder than people think. It’s a form of art, really.

QEMU on Wayland unusable, because it can’t grab the mouse … I’ll add it to my TODO list and investigate/report it eventually.

Someone did a thing:

https://social.treehouse.systems/@ariadne/114763322251054485

I’ve been silently wondering all the time if this was possible, but never investigated: Keep doing X11 but use Wayland as a backend.

This uses XWayland’s “rootful” mode, which basically just gives you a normal Wayland window with all the X11 stuff happening inside of it:

https://www.phoronix.com/news/XWayland-Rootful-Useful

In other words, put such a window in fullscreen and you (more or less) have good old X11 running in a Wayland window.

(For me, personally, this won’t be the way forward. But it’s a very interesting project.)

@movq@www.uninformativ.de Holy crap, that’s really crazy!

Hahaha, you got me. When I read your first sentence I thought you were going to tell about your Wayland experience in comparison to X11. :-D

it’s been while since I’d stopped #window-manager hopping and just settled with #Herbstluftwm but I’m NGL, the River #Wayland compositor is starting to grow on me… I’m still not sure if it’s just me but something about it feels clean and snappy. The shortcuts in the vanilla/example configuration feel a bit clunky, but then again, it’s just me being used to the same old ones I keep adopting and replicating across WMs. I’ve got 0 energy for ricing so I’ll just roll with the vanilla config as is (maybe add in a short-cut for a launcher but that will be it).