> It's absolutely impossible to ask, as everyone will demand everything, claiming even the smallest feature is the foundation of all modern computing.

The problem is they want it both ways. If they're not willing to support literally every use case that X supports, then Wayland should merely exist alongside X, like Emacs alongside vi, rather than removing X from so many distros and desktop environments.

1. Display servers are highly security sensitive and cannot be shipped in good faith unless they are well maintained. The only high-profile X server still around, xorg, is entirely unmaintained outside its Xwayland support, and no one is willing to step up.

Volunteers own their own life and time within it and have no obligation to pick up arbitrary projects and tasks. The primary way to make people do something no one volunteers for is to hire them and pay them for it, but no one is interested in that either.

(One person did famously, and very vocally, volunteer and do a lot of work, but unfortunately almost all of it had to be reverted recently after it was found to break everything.)

2. Wayland and X does, for and enduser, coexist through Xwayland. You just no longer run a "native" X11 display server that controls hardware directly. Most Wayland servers afford Xwayland some slight additional controls for just the X11 windows, allowing applications to work seamlessly, so everything is fine.

And no, the "most" qualifier is no issue at all as applications relying on such control also only worked with some X11 window managers.

> The historic reason is that all inputs and window manager state outside your very own window is kept secret, and "stealing" input strictly disallowed.

For multi-window applications you're not inside "your own window", you own many windows. Are apps not allowed to get and set properties of windows they spawn under Wayland?

I haven't worked on desktop UI in years, but that's very surprising to me if true.

A window (surface in Wayland speak) is just an object in the Wayland protocol, and a Wayland client can have as many as it likes - it will just never see anything outside its windows. If these are normal windows (top-levels), it won't even know where the windows are relative to each other - it just receives (surface-relative) input when focused, none when not.

Note that Wayland objects including surfaces does not have "properties", just requests and events. You create a surface object, create an xdg_toplevel role object to make it into a moral window, and send requests to attach and commit buffers with content, to request fullscreen, etc. In turn you get events if the display server would like you to change state, when it's a good time to start painting, etc.

It's not like X11 where a window is an arbitrary key value store that you write stuff to and cross your fingers in order to get particular behaviors.

> If these are normal windows (top-levels), it won't even know where the windows are relative to each other - it just receives (surface-relative) input when focused, none when not.

So a very basic problem in a multiwindow app is: open a new window. Move it around. Close window. Reopen window, and reposition it where the user last placed it.

Normally that requires windows knowing where they are in absolute coordinate space on the display. From what it sounds like, that's not possible in wayland?

Note: I don't think it's productive to talk in terms of Wayland or X11 abstractions or terminology, since the problem is very simple and something that's pretty trivial to do on any desktop for the last ~25 years. Regardless of how Wayland presents the data to an application we can agree: an app opens "windows", a user moves them around, and then the app may want to recreate equivalent windows at the same position later, right?

I don't miss the X11 days where I had to patch restoring window positions out of every application that did so. Good riddance.

Just that last time I had the application on a side monitor doesn't mean it should move itself after launching. Its especially bad if you often reconfigure monitor layout (for example laptop sometimes using external monitors).

> Reopen window, and reposition it where the user last placed it

Under Wayland, this is not the responsibility of the application, but the responsibility of the display server. You tag the window using the new toplevel tag protocol, and the display server will remember things like user position, size, always-on-top settings, and similar.

> Normally that requires windows knowing where they are in absolute coordinate space on the display. From what it sounds like, that's not possible in wayland?

It is neither possible to know where a window is nor to place it. That is purely up to the server, and under Wayland the goal is to tell the display server what it needs to know to create the UX the user would want - with a recurring focus on respecting user preference over having applications enforce the developer's preference.

But, it's important to note why it's made the display server's reponsibility: because the alternative was already broken under X11. Take a multi-window app that wants to open an old-fashioned "tool" menu. The application wants to place it to the left of the main window, which seems simple - until you realize it's not.

If the window opens fullscreen, the window would end up off-screen or on a different screen - okay, so we check if we're fullscreen and overlap the window instead. If the window opens near a screen edge or on a small screen, it might be too close to the edge - okay, so we also check if the left side of the main window is near a screen edge. Simple enough so far.

But then you run a tiling window manager (i3, awesomewm) and all new normal windows become tiles that pop up after predetermined rules, and random floating windows will be an error. Or you run PaperWM or Niri where the screen has an infinite horizontal size and so checking if a window is near an edge is always incorrect as the edge moves as needed. Or you run a VR window manager (we have those now!) so windows have not just X and Y, but also Z, pan, tilt and roll that the application does not know how to manage. Or you have a display server running on one of the OLED monitors that fold in and out like a recent CES lenovo laptop. Or...

Applications trying to micromanage their windows are effectively re-implementing a window manager that is always going to be making very heavy and wrong assumptions about the current window management paradigm and end-user preference. Instead of porting already broken duct-tape from X11, Wayland works on protocols that describe the intent properly - for example, by describing that an auxillary window is associated with the parent and should default to a placement to the left of it, rather than manually moving it.

(My personal opinion, unrelated to any project, is that traditional multi-window is a very fragile legacy design paradigm that doesn't make any sense, and that keeping operations to a main window and only using windows for isolated tasks - e.g., different workspace, file selectors, etc. - gives much better and more stable UX. Splash screens also no longer belong in a world of multi-tasking - just open the main window immediately, and if the app needs additional time to prepare, show the "splash" in the main window and transition later. That way, the user can multi-task and place the window instead of being interrupted by an application thinking they should cover up the center of the screen and randomly glitch windows in an out of existence.)

</walloftext>

> My personal opinion, unrelated to any project, is that traditional multi-window is a very fragile legacy design paradigm that doesn't make any sense

That's all well and fine, no one is forcing you to build or use software this way. But there are domains where this is the predominant UX design and it's proven to be robust for decades.

Reading between the lines a bit and from browsing some mailing list posts/gh issues, it seems like Wayland developers have a deeply held arrogance towards application developers that are surprised to find out the applications they have been developing for years are "wrong." The truth is that GUI software on Linux is already a minefield (which is why most people don't bother to support it) and making it less-like-Windows is not going to make it easier for people to port their desktop applications. I get the desire for targeting things-not-like-Windows (tiling WMs, VR, tablet/mobiles, etc)... but those aren't desktop applications.

It seems crazy to me that there's so much feedback from desktop application developers that is being ignored or dismissed.

> That's all well and fine, no one is forcing you to build or use software this way. But there are domains where this is the predominant UX design and it's proven to be robust for decades.

Nothing about it is robust, it just exists. It has been around for decades, sure, but it also has not been common or popular for at least a decade or two now. It primarily exists in old applications still rocking their original, unchanged UI.

I have sympathy for existing applications, but I strongly believe it would be entirely inappropriate for a new application to be written with such UI - it was never a good idea, nor did it ever work well. It was just an idea that we have moved on from.

> It seems crazy to me that there's so much feedback

Not specific ot Wayland, but there is always absurd amounts of "feedback" to any high profile projects, which unfortunately means that most of it is useless noise, hit-and-run tantrums over the mildest inconvenience, and "ideas for solutions" by people who spent less than 5 minutes trying to understand the problem. This in turn means that it can sometimes be harder than it should be for good feedback to make it through.

> For multi-window applications you're not inside "your own window", you own many windows. Are apps not allowed to get and set properties of windows they spawn under Wayland?

Depends on what you're calling properties of the window, wayland does of course have a number of things like that but not all of them are the same as X11 used to be. I don't believe it's got a way to get the position of your own window, and does not have a way to set the position at all since that's considered a property of the compositor's handle on the surface IIRC (not exactly the same as the window, since the compositor can be putting decorations on the surface like the title bar, controls, etc.).

A lot of it is consequences of moving some security fences around as other commenters have mentioned, because over the decades a lot of applications (not necessarily on linux or X11, but it has happened there still) have used those other barrier's leakage to do nefarious things like steal passwords, pop up ads on top of what you're doing, etc.

I would definitely support an argument that they swung the pendulum further towards "secure by default, even at the expense of what people need" but I'm actually happy they did, because it's quite a bit easier to add the functionality in after you've got something that's secure, rather than design a new barrier that breaks existing things after the fact.

> Depends on what you're calling properties of the window, wayland does of course have a number of things like that but not all of them are the same as X11 used to be.

Well, technically Wayland has no such thing as properties. It only has requests and events on objects, and no protocol behave like an arbitrary key value store the same way X11 atoms do.

You can't ask Wayland how big your window is or should be for example, you decide how big it is right now when you submit a graphics buffer in a requests, and the Wayland server will tell you in an event if it would like it to be a different size (say, because someone dragged a server side decoration or because the window became fullscreen).

A key difference between Wayland and X11 is that Wayland is very explicit in how functionality is defined and added.

The balance doesn’t necessarily require that much thought or deliberation. It could be as simple as putting things like cursor control behind a permission dialog, with it being mandatory to provide a reason why the capability is needed to present in the dialog to help users make an informed decision.

Web browsers tried that. Then spam sites started saying "press allow to prove you're not a robot". Android showed a whole list of permissions for years whenever you installed an app. Nobody ever read them, phones were full of malware, and Google started nuking APIs and replacing pre-install permission prompts with real-time permission prompts.

If letting the application ask nicely is a good enough security measure, then you never needed to ask in the first place. When a user wants to use an application (or, what they think an application does), and the application just says "for the app to work" when the OS queries it for a reason why it needs permissions, the user is going to click permit every time. From a practical security standpoint, the application could just as easily say "I'm going to take control of your mouse OK/cancel". Which is what happens on X11, except applications just take control of your mouse whether you want to or not.

There’s some crucial differences here, though.

The web is a different beast because people will visit sites on a whim, plus there’s things like redirects to factor in. Friction for visiting sites is very low, which makes the spam problem much worse. Users’ desktops are a very different environment — nearly all programs that are installed are there because the user explicitly willed it. Apps can’t install themselves and users install apps at a much lower rate than they visit sites, and so the only time there’s a “spam” effect is when setting up a new machine (which could be ameliorated by account migration tools copying permissions). Furthermore, if apps start acting abusive there’s a good chance that users will remove them and seek replacements, and so it’s in apps’ best interest to not do that.

As for Android, that’s simply a bad permissions model. The iOS/macOS model in which prompts are shown when the user tries to use an associated feature is much better and appropriately triggers mental red flags when incongruent permission requests appear.

It’s never going to be perfect, but third party devs have repeatedly proven that full access to everything all the time is not a model that works for anybody but power users and above.

The permissions setup seems to work fine on macOS though. I can grant an application permission to view and manage other windows. Doesn't flatpak have user configurable app permissions as well?

I don't see how all-or-nothing is better than letting the admin whitelist what they need and blacklist that they don't

It's actually a lot more difficult than that.

Working with existing applications as is requires a ditect mapping, and any restrictions or asynchronous prompts would break any existing assumptions in platform agnostic code, so it wouldn't solve things completely.

If you make something possible to do something with a permission or configuration, app developers just tell users to accept or configure to not ask, and then we're worse off than if there was no permission at all: the security is bypassed and only the inconvenience remains.

It takes a surprising amount of thought and work to do this in any meaningful way, and it cannot be done in a way that isn't somewhat disruptive.

It’s a bit crude, but macOS handled the asynchronous prompt problem by suspending the process trying to access something it hasn’t been given permission to use until the user has acted.