3 ms·

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

• simcop2387 1y ago
  > 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.
  • arghwhat 1y ago
    > 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.
• arghwhat 1y ago
  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.
  • duped 1y ago
    > 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?
    • arghwhat 1y ago
      > 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>