[MegaDeKay]

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.

[senfiaj]

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.

[dormento]

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

Makes me mad.

[senfiaj]

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

[kmeisthax]

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.

[bombela]

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).

[kelnos]

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.

[senfiaj]

>> 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.