Hacker News Reader

Comment by senfiaj | Hacker News Reader

What's sad is that after many years Wayland still lacks several things/features that X11 has/allows. Some of them are intentionally not implemented because of security paranoia. For example, Chrome "picture in picture" window doesn't stay on top when I click somewhere else since Wayland doesn't allow windows to stay on top. If I had a lot of time I could list how Wayland breaks many applications.

Not saying that X11 is not broken and should not be replaced, but many Wayland's decisions harm user experience more than X11.

View on HN

I have a virtual pinball cab with two (and soon) three displays. Wayland really makes life difficult here because the software needs to always put the playfield on one display, the backglass on another, and the "dot matrix display" window on a third. That's a big no-no with Wayland. Fortunately KDE has window rules as a workaround. Sway and Hyprland allow similar rules. Mutter on Gnome has no equivalent.

I'm guessing this would mess up other games as well, like multi-screen flight simulators or driving games. It would be really nice if user-trusted apps could be granted permissions on an app-by-app basis to allow absolute placement of windows for these cases instead of making us jump through hoops.

Yes, exactly. This security paranoia makes the devs' lives much more complicated. I have seen many apps turning off advanced features, such as screen color pickers. Automatation tools can be broken. Apps cant know their window positions, etc. You can see countless dev rants about Wayland and how it's generally unpleasant experience to work with.

Ah so that's why i cant use the chrome devtools color picker to pick colors off graphics editing software.

Makes me mad.

Yes, on Wayland the color picker can only pick inside Chrome window.

Ironically, the use case you described is exactly the sort of thing Wayland really excels at - if you're willing to write your own compositor. There's plenty of embedded devices that ship with an extremely simple Wayland compositor that does exactly this. It opens up one app, accepts as many windows from that app as it has displays, and renders one window per display. That's that. There's no super-secret desktop that could wind up accidentally displaying if the app crashes or gets its window accidentally moved about, because there's no desktop and no moving any of the windows. You just take output from an app and put that on the display, then send input back to it.

This is great. But this doesn't cover the general expectation of a desktop application.

I want application to know the screens, send windows to know positions etc etc. And this is now compositor specific. So some applications will know how to talk to the kde compositor to share the screen, or place a window at a specific position (very useful for so many things).

That's strange; you should be able to do that with the standard xdg-shell protocol, though I suppose it depends on the app's behavior. The app can tell the compositor which output to fullscreen each window on.

Alternately, if it's using layer-shell windows, those can also be pinned to a specific output.

If it's not layer-shell, and the windows aren't fullscreen, then yes... it's annoying. The xdg-session-management protocol will likely fix that in this particular case (at the expense of having to manually place the windows in the right places once, and then it can remember in the future), but that protocol has just recently been stabilized and of course no one supports it yet.

It's all so frustrating watching the Wayland folks reinvent everything, poorly, and after more than 10 years it's still not there yet.

>> It's all so frustrating watching the Wayland folks reinvent everything, poorly, and after more than 10 years it's still not there yet.

The whole project started in 2008, so almost 18 years.

If you use KDE, you can work around this because of the powerful feature set the window manager has for setting custom window behavior.

1. Right click the PIP window and then click "More Actions-> Special Window Settings".

2. On the window that pops up, click "Add Property", and add "Window title". Change the drop-down from "Unimportant" to "Exact match" (this works on Firefox because the window title is always "Picture-in-Picture", you might have to do something slightly different on Chrome if it does something different).

3. Click "Add Property" again, add "Keep above other windows", change the drop-down to "Force", and change the radio button to "Yes".

4. From now on, all PIP windows will show up on top of other windows.

It would definitely be nicer if there was some sort of "always on top" permission that applications could request, but it's not too bad.

For Chrome it's "Picture in picture"

Not too bad? A hidden procedure with ten clicks, which the user has to repeat for each web browser. And it may break at any time if the browser changes some details. Or if KDE changes. And it's specific to KDE, with no alternatives in most Wayland WMs.

All that for _one_ feature which works out-of-the-box with Xorg, and which Wayland removed for security reasons. From what I've seen, sharing the screen is another common feature which was broken with Wayland and is still painful.

I don't think Wayland's security model is very relevant to me since I have faith in Debian for filtering out rogue applications. So I have to reason to drop my smooth UX for a world of "not too bad" workarounds.

Look, I'm not a Wayland booster, I still prefer X11 most of the time, but this is really the way it should work. Applications should not be allowed to dictate how windows appear. That is the job of the window manager. Chrome's PIP is a stupid workaround for Windows and Mac because they do not have robust window management.

>> Chrome's PIP is a stupid workaround for Windows and Mac because they do not have robust window management.

What are you talking about? It's very convenient when I watch video while I do some work or entertaining thing on other web page or app. It's fine if you don't want to use it but many people do.

Yes, it's fine, but it shouldn't be necessary. If Windows and Mac OS just had native support for always-on-top windows, you wouldn't need it.

I actually prefer macOS's PiP handling compared to other operating systems. In that it's a blessed concept that only goes to one corner of the screen and can be shunted out of the way easily.

Now imagine if that was designed properly, and you could just do that to any window, regardless of what the program thinks it should look like.

I use pinned (always above + on all workspace/desktop) quite often.

And to make it ergonomic I scripted kwin and set some shortcuts.

So yes, you can have any window PiP the way you like. But it requires you to do a long sequence of actions. Versus a single click for very specific PiP behavior.

Consider a window in a web browser tab. You could click the PiP button, which will pop out a tiny window, most likely already in a corner of the screen. This window is a mini video player. Your original browser tab stays untoucher, still at the same place in your web browser tab list, the rest of the tab still readable and scrollable etc etc.

Or, you could clone the tab. Move it to its own window. Locate the video. Put it in full screen. Un-fullscreen the window. Click on the pin button. Resize the window to the corner.

Same result, but not the same effort.

Windows has had native support for always on top windows for over 25 years

This is the issue with imposing semantics of the programming model on the behaviour.

User behaviour is the only _real_ thing, it happens. Everything else is in your head. If people in the real world use PiP, then it should happen. The programming model has to bend and change to support it. It simply does not matter if the window manager does something or the window does something.

Sure, there is always the security argument wayland folks fall back to. But what ever is the problem with making a one-time permission popup? "Google Chrome wants to open in PiP: allow | allow once.". Just expose the existing PiP code in the window manager as an API guarded with an `if` that apps can call. It's not even that much real work, just pure bikeshedding and architecture astronauting.

Right right, and I'm not saying users shouldn't be able to have a floating window with video (or whatever) in it. I'm saying it shouldn't be Chrome making that window floating and always visible.

I don't get it, if you're on google meet, and you want to make one of many videos PiP. How can you ever do that in the window manager? It has to be done in the application! You right click or click on the menu on that particular video, and click Picture in picture.

How the heck can the window manager do it?

The application could tell the window manager it wanted an always on top window. The window manager could ask the user if it should allow or reject and remember for this application or not.

That's exactly what I said... and also not how wayland works.

I cannot comprehend the way wayland folks think... quote from the xdg-pip discussion:

> To not make PiP windows effectively "always on top" and "on every workspace" dialogs - a terrible and sadly by applications used concept on X11 - PiP windows must be input-only, i.e. not receive keyboard, pointer and touch input

Like what the heck even? That is how pip windows are expected to work? And of course you want inputs on them? e.g to mute/unmute on a video call? Like these are use cases used daily by people. And its "terrible".

I also don't get it with the wayland people. It feels like they want to revert everything to a UX design that was getting old in the 90s.

They want to turn everything into an appliance.

If things were designed well, it would be as easy as clicking the pin icon on the window border.

How many buttons do you want on a window frame then? The typical 4 buttons already take a lot of space in the title bar. Not everything that seems like a good idea at first glance is actually good design.

I've fucking had it with you people and your "design"

As many buttons as he thinks he needs, and as a compromise they can be disabled by default and enabled through settings. Instead your ilk will probably remove even those remaining buttons and replace them with some obscure movement command

No, I wouldn't. I'm not your enemy. Please don't antagonize people like that. It's rude and I considered not replying because of your tone.

I have a pretty strong oppinion that GUI basics must be simple but more advanced stuff (e.g. tools that trainee professionals spend most of their workday in) must not hide its raw power because the user can be expected to learn.

User interface essentials have to be understandable without mental gymnastics by default without appearing overwhelming. The overwhelming majority of computer users don't change defaults on most software and a shockingly big number of computer users deal with them only because they must, not because they derive joy from it. They don't engage deeply with these devices at all. So those defaults must be picked carefully to keep the UI approachable. This isn't the same as ripping out features or antagonizing power users that do bother to learn.

I don't know man, everybody is fine with putting tabs, and searchbars, and a bunch of other shit in the titlebar, but god forbid we put one button that's actually incredibly useful.

Try to move a browser window when you have 20+ tabs open. This is an incredibly bad UX.

alt + left mouse button anywhere in the window (maybe win button or something is default now).

using the titlebar for moving a window is extremely backwards and productivity killer.

that being said, I agree with you, and I think its an outright abomination to put the tabs in the titlebar, and its disgusting how crome and firefox by default removes the real titlebar

Alt+LMB drag is impossible to do properly, at least on Windows, because too many applications use that for their own inputs. There are some X11 applications that also use that (Blender?), so while it's cool when it works, it comes with pretty severe problems.

there might exist some programs that do it, but this might be why they changed default from alt to win key.

in either case, that appears to be the very extreme minority of cases you have to move a window

Alt-drag works perfectly well on windows. I use a third party app called alt-drag to enable it. Has worked fine for years.

It also allows you to use it with win-drag of course.

That's what I have in my setup, six titlebar buttons: send to other screen, sticky among workspaces and always on top in addition to the base 3. Can't imagine ever using something that gives me less control again.

That expectation is really an immediate major UX defect. Most really good GUIs rely on tons and tons of subtle behaviors to work right (that is, to assist the user). That means - counterintuitively - that they need a lot of leeway in how they get to control their own windows to appear on the screen.

Ultimately, the screen is just an unbroken flat surface and windows are just a software level abstraction that has been tortured beyond hope and one that users shouldn't have to micromanage or understand deeply.

If an application needs something to appear at a specific spot in a specific way, the display manager needs to bend over backwards to make it happen or it's broken. Windows understands it. MacOS understands it. X11 understand it, but the community is working hard to throw that wisdom away.

Finally a sane answer

Permission prompts still only allow things that have already been thought of so we will see less innovation in the future. I don't think this kind of security model is needed at all for an open source desktop where we can enforce directly that programs respect the user instead.

The job of the window manager is to manage windows if the user wants it to do that. However there's many situations in which users want the application to be in charge of window positioning.

Making a decision on the user's behalf doesn't sound very free to me.

Note there is also a far simpler one: You can right-click the window on the taskbar and click Keep Above. This works for any window.

But then you'll have to do it every time.

> I have faith in Debian for filtering out rogue applications

Sorry but all I can say to that is: lol

As for security, it's easy/possible to cut holes into a solid wall. But if your whole system is swiss cheese, you can't plug all of them in. Wayland is a solid wall where protocols are the means to cut new holes. Sure, protocol development is slow (at least their acceptance), but this is the proper way to do it.

And even if you have faith in your applications, do you also have faith in your data? Because it's a mostly C/c++ application set, one vulnerability is enough to make them malicious. And with the beautifully engineered default "GNU/Linux" userspace security model, the only thing a random script can't do on your machine is install a new video card driver. But everything else is under the same user and readily accessible with full network access.

Debian applications are not sandboxed so gimping the window system gains you exactly nothing. And yes, we can expect Debian to filter rogue applications.

Wow, I guess Linux is only free if you don't value your time.

I tried this for getting windows to open where I want them instead of the center of the screen. Couldn't figure it out in five minutes. Though I'll probably try again, this shouldn't be a problem.

One difference I notice in x11 gnome vs wayland gnome is firefox's PIP window is always on top on x11 even if I deselect "Always on top" (super + right click menu) in wayland that works fine and is even always on top by default.

I much prefer the latter, especially since I get the choice.

My Wayland pet peeve:

It still lacks keyboard LED control, so unprivileged X11 programs that use the Scroll Lock light as an indicator cannot be ported to Wayland.

This Plasma change is going to be painful for me. I wonder if there's an up-to-date list of Wayland shortcomings.

> unprivileged X11 programs that use the Scroll Lock light as an indicator

I didn't know such apps existed! What do they use it for?

One use case is a new message indicator. Unlike icons on the desktop, keyboard lights are visible even when a full-screen application is running, or when we're to the side of or across the room from the computer, or when the display is asleep. I depend on this for my daily communications.

Another use case is for keyboard macro utilities to indicate the state of layers, modifier modes, or multi-keystroke input sequences.

Others surely exist, since hardware lights can indicate just about anything, and are especially valuable where visibility is important. Even shell scripts can use them on X11, via the xset command.

Which programs can be configured in this way? Something custom you wrote?

assign yourself permission to the device(may or may not happen by default depending on your distribution), and you can actuate it in /sys/class/leds/inputXX::scrolllock/brightness.

probably also exists other tools to do it. this is then generic linux LED framework

I am aware of sysfs LED controls. They don't solve this problem, because access to them requires privileges (or permissions assigned by someone with privileges). It's not reasonable to expect that, just as it's not reasonable to expect a sysadmin to grant users permission to the keyboard device node before they can type anything.

Moreover, granting permissions on the sysfs nodes won't distinguish between a user who is logged in to the current virtual console and one who is not. Wayland correctly delegates keyboard ownership to compositors, but they have no way to expose the keyboard's outputs (the LEDs) because Wayland hasn't yet defined a protocol for doing so.

X11 has a protocol for this, and X servers handle it just fine. They account for different users and LED states on each virtual console, and do not require clients to have any special permissions. It's an area where Wayland fails to be a suitable replacement.

Isn't it also impossible to spawn a window in the last place it was open (or any arbitrary point) because you're not allowed to know or change where your window is by design? Nonsense like that makes me dread having to eventually use it.

They "fixed" that by implementing multiple conflicting and optional experimental extensions that may or may not randomly be supported by your particular WM/DE, and may or may not be DE-specific protocols in the first place.

https://wayland.app/protocols/

are there really multiple confliction extensions? I thought they finally actually agreed on a protocol to do it?

Ah, for some reason I figured this was a minor bug that'd be fixed eventually. Wayland windows are never allowed to spawn always-on-top? Sort of lame.

If the logic is that it's the window manager's job to set window rules for this, fine, but in that case Plasma should probably ship with preconfigured rules matching the Chrome/Firefox PiP window.

I also find the lack of an Xlib-compatible macro API disruptive but I usually run an X11 session inside Xvnc for this purpose anyway.

I know nothing about the detailed technical differences between X11 and Wayland but with Hyprland for me the PIP is working as expected so I assume its not just a Wayland issue but specific to the window manager you are using? Maybe somebody else can explain?

Gnome has a "Always on Top" toggle for each window. I imagine there's a protocol for an application to set it by default but the OP's window manager might not implement it or there might be an incompatibility.

Plasma/KDE always had it.

But users do not want to have to toggle that for every PiP video they watch. Its why I am still on X11

I can't speak for Gnome, but KDE makes it pretty easy to create rules that apply automatically to any new window that meets whatever arbitrary criteria you set.

That's terrible. That's an "unbreak my software" preference. User's shouldn't have to mess with that; things should just work in ways they expect, out of the box.

I disagree. With how KDE handles this, I'm not at the mercy of the software vendor's whims on what windows stay on top and which ones don't. I have complete control through a standardized interface that can even be automated if I wish.

Does it require a little more knowledge on the part of the user? Yes, but it's worth it because with that knowledge comes power.

Gnome has the same problem, that's why this exists: https://extensions.gnome.org/extension/4691/pip-on-top/

Isn't that usually how it goes? Wayland is a million little optional protocols, which in the abstract is a lovely idea but in practice means which things work depends on which grab-bag of features your compositor supports.

It's a bit like the web. You have a pretty slow moving list of "protocols" that are well-supported by everyone, and some "new experimental" ones that are only supported by one or two.

As far as I know, there are multiple Wayland implementations. Which is also not good because it creates fragmentation and potential inconsistencies (some subtle differences in behavior, differences in bugs, etc). Maybe Hyprland solves the issue, but I don't want to use this DE just because it solves this particular issue. I have tons of other needs and preferences.

I think in Hyprland it just works because floating windows stay on top by definition.

I fixed this like this:

1. Right click PIP window 2. More Actions -> Configure special window settings 3. Add property -> Layer Force Popup

After this it spawned always in middle, I also added property Position Remember, so it spawns where it was previously. I have no idea if this is the best way to fix but worked for me.

> doesn't allow windows to stay on top.

Are you sure that windows that, without your consent, are allowed to stay on top and grab your input are a good idea? And spawned by Chrome? As if we hadn't already enough ad-ware, click-harvesters, and spoofed dialogs popping up everywhere!

I know there is a couple of legitimate uses for this, but the ways it can be abused are vastly more.

I think the sensitive default should be to block it, and allowing it should be behind some user's conscious action. Yes, it adds some friction to some workflows and it takes a bit to get accustomed to. But it doesn't deserve the label "security paranoia".

Are you aware that if software misuses the capabilities its given by the system you can choose to stop using that software?

True. But it's often all or nothing: you can't surf the web without the ads.

You can't do anything about a compromised app or JS from a random website. I always find it weird when people attack Wayland's security model, more isolation is obviously a great idea, as demonstrated by supply chain attacks in the recent decade.

It's that Wayland's design, implementation, their attitude, and everything else about it is terrible. It could have been implemented without compromising on features or convenience by explicitly specifying minimalistic controlled side channels in their security model from the start, instead of shifting it onto ad-hoc implementations. And of course the windowing system is already too large of an attack surface. Many people are thinking about going full Qubes due to the current realities, while the others live in denial and call even window isolation "paranoia". Fascinating.

Turn off the web browser feature that allows JS in an advertisement in a background tab to globally grab your input.

Sure, browsers had three decades of adversarial testing to evolve into sandboxes, but what are you going to do in case of something like the xz backdoor in a desktop application? It's no longer a hypothetical in 2020s.

You're going to be hacked. There's no useful middle ground between letting programs modify how your computer works and not letting programs modify how your computer works.

Of course there is: fine-grained access control and attack surface reduction. It's not all or nothing.

Do you want to see the dancing bunnies? [Yes] [No]

Apple apologists keep making the excuse that Apple has to provide no side loading because if there was any single way to do it, all scammers would be making all grandmas do that. They're correct.

That's a complete strawman though, I'm not talking about any of that.

I can't speak for Chrome, but I can right click a Firefox picture-in-picture window, tell it to remain on top, and it does, no problem. I've been using Plasma Wayland for years now and this has worked for ages

The issue is you have to do that every single time. On X11, they remain on top by default

There is some resource leak in Chrome / Wayland combo, I mysteriously run out of memory after few days of keeping several Chrome windows. On X11 Chrome can keep going pretty much indefinitely

Strange... with Firefox in KDE/Plasma just works.

I definitely have to right click on the window in the taskbar and select Always Keep On Top with Firefox on Plasma Wayland. Not too big a deal but would be nice if it was something Firefox could just set on its own.

> Chrome "picture in picture" window doesn't stay on top when I click somewhere else since Wayland doesn't allow windows to stay on top.

Wayland doesn't allow apps to force themselves to be always on top. I would argue that it is up to the window manager to provide this functionality at the discretion of the user. Kwin does this.

I would argue that software that I choose to install already has my discretion and should not be limited by the windowing system in what it can do.

> Wayland doesn't allow windows to stay on top

I use Wayland and it has a "stay on top" option for windows.

Reply on news.ycombinator.com