4 ms·

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

by 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>
- duped 1y ago
  > 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.
  - arghwhat 1y ago
    > 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.
accelbred 1y ago
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).

by duped 1y ago

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>

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

accelbred 1y ago

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