4 ms·

This discussion about monitor-aware positioning of windows relative to another is a real treasure trove: https://gitlab.freedesktop.org/wayland/wayland-protocol

by v1ne 3y ago

This discussion about monitor-aware positioning of windows relative to another is a real treasure trove: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... One post summarizes it pretty well. Jehan says: > As GIMP maintainer, do you want me to open a separate report so that we explain our use case on multiple windows, as well as future planned use cases? I find it fascinating. There is this supposed successor to X11, but it breaks a lot of existing applications, telling them that they are wrong. Because layout shall be done by the compositor, not by the application. True, traditional desktop systems make a lot of invalid assumptions like Windows with a global physical pixel grid that makes it pretty tough to display windows which span multiple monitors with different DPIs correctly. Yet still, they get one thing right: Positioning is a job shared between the application and window system. Because only the application knows the semantics in detail. Completely ignoring that and insisting on the application to only express these semantics via a previously-agreed upon protocol sounds pretty arrogant to me. This means that details will be lost. It's not up to the protocol designers to decide which semantic details are important. That's up to the application designer.

jahewson 3y ago
I don’t know, deciding not to support multi-window mode seems ok to me. It’s a relic of the past and dragging around all that baggage often isn’t worth it.
- danaris 3y ago
  ...Now, I haven't used Linux regularly in a long time, so I may be misunderstanding, but unless "multi-window mode" means something very different than what it sounds like, it seems ludicrously arrogant to be declaring it a "relic of the past". Do you think every application should use no more than a single window, and fit its content inside that? Rather than being able to have a window for the main content, a tool palette, an information window, etc? Just because that's the only kind of application you can imagine wanting to use or make doesn't mean that should be the only thing allowed.
- westyvw 3y ago
  Tell that to the people who like replicating their Workspaces at home using a remote connection that works everywhere on every OS....unless you are using Wayland.
pkkm 3y ago
Oh, that's just one of many such cases. There's also the history of how it took years of requests, and pressure from Valve, for Wayland devs to consider letting the user disable VSync. Or the disaster around the UI scale, which until recently would be rounded up to the nearest integer, passed to the client, and the client's rendered bitmap would then be downscaled by the compositor to match the actual scale set by the user. Because who needs performance, accurate display of images, or subpixel antialiasing of fonts? Fortunately, they have relented on this too and a fractional scaling protocol got merged. Unfortunately, it basically obsoletes a core protocol field. It's a whole repeating pattern: Wayland starts out with a weird and inflexible design -> Wayland devs try to make the whole Linux ecosystem conform -> they start backtracking after years of pressure, but now they have to add cruft/workarounds to the protocol. Happened to forced VSync, integer-only UI scaling, the compositor-driven render loop with no visibility hints, client-side decorations only... At this rate, Wayland will be full of obsolete cruft before it even overtakes X11 in popularity.
devit 3y ago
That's obviously the only correct approach. The concept of "window position on screen" makes no sense, since a compositor is allowed to display windows arbitrarily, and doesn't necessarily display them as 2D rectangles (for instance, they could be displayed in a VR environment at arbitrary 3D positions, or they could be warped arbitrarily, etc.). Also, the window layout belongs to the user and compositor and it would be a security hole to let applications affect it. If you want to position subwindows, you need to draw the subwindows yourself inside a main window like e.g. VSCode does with its various panes.
- mcpackieh 3y ago
  > The concept of "window position on screen" makes no sense, since a compositor is allowed to display windows arbitrarily, and doesn't necessarily display them as 2D rectangles (for instance, they could be displayed in a VR environment at arbitrary 3D positions, or they could be warped arbitrarily, etc.). This is a poorly thought out objection (sounds more like a rationalization), neatly addressed here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247#i-have-a-tiling-wm https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... > No problem! For window managers like this, it is perfectly legitimate to just ignore the client’s positioning requests. The API specifically mentions that clients should not rely on absolute placement to happen. It is merely advice to the compositor to choose a sensible initial spot to put a window. Same goes for weird form factor displays or specialized compositors, of course (but those may not even implement xdg-shell at all).
  - PH95VuimJjqBqy 3y ago
    I'm pretty sure this has always been the case and is how the desktop standardization stuff works now in X11.
    - mcpackieh 3y ago
      Yes exactly, tiling window managers frequently ignore applications trying to set window geometry. It need be no different for exotic VR wayland compositors or whatever else anybody has in mind. The existence of a protocol for setting window geometry and positions obviously does not mean every compositor must respect those requests.
bb88 3y ago
It is fascinating. And the answer he was given was "Yes"! And then given the rate at which protocol changes happen, it will take YEARS to do anything. Sebastian Wick said this: > If we add a protocol like this, there is no going back. We will be stuck with it forever and have to live with this pain for the next 30 years when someone finally manages to write a successor to wayland that's willing to break backwards compatibility again like wayland did. They're looking for "perfection for the next 100 years" instead of "good enough for now".

by v1ne 3y ago

jahewson 3y ago

I don’t know, deciding not to support multi-window mode seems ok to me. It’s a relic of the past and dragging around all that baggage often isn’t worth it.

danaris 3y ago
...Now, I haven't used Linux regularly in a long time, so I may be misunderstanding, but unless "multi-window mode" means something very different than what it sounds like, it seems ludicrously arrogant to be declaring it a "relic of the past". Do you think every application should use no more than a single window, and fit its content inside that? Rather than being able to have a window for the main content, a tool palette, an information window, etc? Just because that's the only kind of application you can imagine wanting to use or make doesn't mean that should be the only thing allowed.
westyvw 3y ago
Tell that to the people who like replicating their Workspaces at home using a remote connection that works everywhere on every OS....unless you are using Wayland.

pkkm 3y ago

Oh, that's just one of many such cases. There's also the history of how it took years of requests, and pressure from Valve, for Wayland devs to consider letting the user disable VSync. Or the disaster around the UI scale, which until recently would be rounded up to the nearest integer, passed to the client, and the client's rendered bitmap would then be downscaled by the compositor to match the actual scale set by the user. Because who needs performance, accurate display of images, or subpixel antialiasing of fonts? Fortunately, they have relented on this too and a fractional scaling protocol got merged. Unfortunately, it basically obsoletes a core protocol field. It's a whole repeating pattern: Wayland starts out with a weird and inflexible design -> Wayland devs try to make the whole Linux ecosystem conform -> they start backtracking after years of pressure, but now they have to add cruft/workarounds to the protocol. Happened to forced VSync, integer-only UI scaling, the compositor-driven render loop with no visibility hints, client-side decorations only... At this rate, Wayland will be full of obsolete cruft before it even overtakes X11 in popularity.

devit 3y ago

That's obviously the only correct approach. The concept of "window position on screen" makes no sense, since a compositor is allowed to display windows arbitrarily, and doesn't necessarily display them as 2D rectangles (for instance, they could be displayed in a VR environment at arbitrary 3D positions, or they could be warped arbitrarily, etc.). Also, the window layout belongs to the user and compositor and it would be a security hole to let applications affect it. If you want to position subwindows, you need to draw the subwindows yourself inside a main window like e.g. VSCode does with its various panes.

mcpackieh 3y ago
> The concept of "window position on screen" makes no sense, since a compositor is allowed to display windows arbitrarily, and doesn't necessarily display them as 2D rectangles (for instance, they could be displayed in a VR environment at arbitrary 3D positions, or they could be warped arbitrarily, etc.). This is a poorly thought out objection (sounds more like a rationalization), neatly addressed here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247#i-have-a-tiling-wm https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... > No problem! For window managers like this, it is perfectly legitimate to just ignore the client’s positioning requests. The API specifically mentions that clients should not rely on absolute placement to happen. It is merely advice to the compositor to choose a sensible initial spot to put a window. Same goes for weird form factor displays or specialized compositors, of course (but those may not even implement xdg-shell at all).
- PH95VuimJjqBqy 3y ago
  I'm pretty sure this has always been the case and is how the desktop standardization stuff works now in X11.
  - mcpackieh 3y ago
    Yes exactly, tiling window managers frequently ignore applications trying to set window geometry. It need be no different for exotic VR wayland compositors or whatever else anybody has in mind. The existence of a protocol for setting window geometry and positions obviously does not mean every compositor must respect those requests.

bb88 3y ago

It is fascinating. And the answer he was given was "Yes"! And then given the rate at which protocol changes happen, it will take YEARS to do anything. Sebastian Wick said this: > If we add a protocol like this, there is no going back. We will be stuck with it forever and have to live with this pain for the next 30 years when someone finally manages to write a successor to wayland that's willing to break backwards compatibility again like wayland did. They're looking for "perfection for the next 100 years" instead of "good enough for now".