5 ms·

On Mac OS, you can ask the WM to store the geometry for you and recreate it. It's exposed to devs via the NSApplicationWindow (or something) API and then backed

by sho_hn 6y ago

On Mac OS, you can ask the WM to store the geometry for you and recreate it. It's exposed to devs via the NSApplicationWindow (or something) API and then backed by a protocol between the app and the windowing server, leaving the latter in ultimate control. Wayland doesn't have an equivalent protocol yet, but this is also how it would be idiomatically done there.

saagarjha 6y ago
But of course macOS also has APIs on NSWindow to move it around, as well as accessibility and AppleScript APIs to do it as a user in a scriptable way. Why the limitation?
- sho_hn 6y ago
  Wayland does have some ways (meaning protocols) to do explicit positioning, e.g. relative to a parent owned by the same client (for popups), that have been standardized. The primary limitation is not to allow clients to set their x,y in the global scene (or even look them up), but there are proposed protocols that allow global positioning in a semantic sense like "I would like to be at the left edge" or "I am an overlay type thing" (z positioning). Some of those are in production use internally to Wayland-based desktop shells, e.g. KDE's Plasma, or used in communities like sway/wlroots+addons (e.g. dmenu implementations). Why not do x,y? It means you don't have this sort of level positioning code in the apps, which are very expensive or impossible to fix after the fact (apps stop being maintained, etc.) when new ideas come up. Say you want to apply a transform to client windows - scale them, or put them into a 3D sphere in a HMD. Wayland compositors have full flexibility there because the apps don't make assumptions.
  - saagarjha 6y ago
    > Say you want to apply a transform to client windows - scale them, or put them into a 3D sphere in a HMD. Wayland compositors have full flexibility there because the apps don't make assumptions. Except that macOS can do all this regardless? WindowServer can do all sorts of transformations on windows, fully independent of the position the window has set for itself. That's how all the fancy Mission Control/Exposé animations work.
    - vetinari 6y ago
      With wayland, you can do this and the apps won't notice because of the limits placed upon them earlier: https://www.youtube.com/watch?v=_FjuPn7MXMs https://www.youtube.com/watch?v=_FjuPn7MXMs Can macOS do it? The point of this demo is not practical usability today, but to demonstrate, that global positioning on the desktop as we know today might get much more complex in future. So why shut the door?
      - saagarjha 6y ago
        macOS can place windows wherever it likes, see Mission Control. It has APIs that can literally reach across processes so you can draw a window’s content as a little “view” in your window if you like, and apply the rich set of CoreAnimation transformations to it. What happens in a case like that is that the window gets placed in a new coordinate system that is orthogonal to its “original coordinates” (since of course it has no idea what would be going on without changes to the application frameworks) and moved and rendered freely. (Again, Mission Control was added with zero work or cooperation on the part of applications, even though they had the “window move” APIs from day one, which was many years prior. I would be entirely unsurprised if one could make a demo like the one you just showed fairly “easily”, barring private APIs and accessibility permissions and such.)
        vetinari 6y ago
        Interesting, thank you.
- ATsch 6y ago
  Is that allowed even when sandboxed? Either way, allowing it from applications is a lot different than allowing it from user scripts or accessibility tools in terms of potential for misuse.
  - saagarjha 6y ago
    Moving your own window around? Of course, I don't see why not: you can literally do this from JavaScript if you own the window…
    - adrusi 6y ago
      In javascript you can't set your window to be borderless and transparent and be drawn on top of everything else so that you can intercept clicks or trick users into clicking on something.
- geocar 6y ago
  Yes and users have to unplug monitors to find windows that have done this. > Why the limitation? Because users don’t want it? We have window managers and some of us are using automatic window managers. The very idea of movewindow doesn’t make any sense in a lot of topologies. Why do you care? You don’t write or use any software that would need this anyway, do you?

by sho_hn 6y ago

saagarjha 6y ago

But of course macOS also has APIs on NSWindow to move it around, as well as accessibility and AppleScript APIs to do it as a user in a scriptable way. Why the limitation?

sho_hn 6y ago
Wayland does have some ways (meaning protocols) to do explicit positioning, e.g. relative to a parent owned by the same client (for popups), that have been standardized. The primary limitation is not to allow clients to set their x,y in the global scene (or even look them up), but there are proposed protocols that allow global positioning in a semantic sense like "I would like to be at the left edge" or "I am an overlay type thing" (z positioning). Some of those are in production use internally to Wayland-based desktop shells, e.g. KDE's Plasma, or used in communities like sway/wlroots+addons (e.g. dmenu implementations). Why not do x,y? It means you don't have this sort of level positioning code in the apps, which are very expensive or impossible to fix after the fact (apps stop being maintained, etc.) when new ideas come up. Say you want to apply a transform to client windows - scale them, or put them into a 3D sphere in a HMD. Wayland compositors have full flexibility there because the apps don't make assumptions.
- saagarjha 6y ago
  > Say you want to apply a transform to client windows - scale them, or put them into a 3D sphere in a HMD. Wayland compositors have full flexibility there because the apps don't make assumptions. Except that macOS can do all this regardless? WindowServer can do all sorts of transformations on windows, fully independent of the position the window has set for itself. That's how all the fancy Mission Control/Exposé animations work.
  - vetinari 6y ago
    With wayland, you can do this and the apps won't notice because of the limits placed upon them earlier: https://www.youtube.com/watch?v=_FjuPn7MXMs https://www.youtube.com/watch?v=_FjuPn7MXMs Can macOS do it? The point of this demo is not practical usability today, but to demonstrate, that global positioning on the desktop as we know today might get much more complex in future. So why shut the door?
    - saagarjha 6y ago
      macOS can place windows wherever it likes, see Mission Control. It has APIs that can literally reach across processes so you can draw a window’s content as a little “view” in your window if you like, and apply the rich set of CoreAnimation transformations to it. What happens in a case like that is that the window gets placed in a new coordinate system that is orthogonal to its “original coordinates” (since of course it has no idea what would be going on without changes to the application frameworks) and moved and rendered freely. (Again, Mission Control was added with zero work or cooperation on the part of applications, even though they had the “window move” APIs from day one, which was many years prior. I would be entirely unsurprised if one could make a demo like the one you just showed fairly “easily”, barring private APIs and accessibility permissions and such.)
      - vetinari 6y ago
        Interesting, thank you.
ATsch 6y ago
Is that allowed even when sandboxed? Either way, allowing it from applications is a lot different than allowing it from user scripts or accessibility tools in terms of potential for misuse.
- saagarjha 6y ago
  Moving your own window around? Of course, I don't see why not: you can literally do this from JavaScript if you own the window…
  - adrusi 6y ago
    In javascript you can't set your window to be borderless and transparent and be drawn on top of everything else so that you can intercept clicks or trick users into clicking on something.
geocar 6y ago
Yes and users have to unplug monitors to find windows that have done this. > Why the limitation? Because users don’t want it? We have window managers and some of us are using automatic window managers. The very idea of movewindow doesn’t make any sense in a lot of topologies. Why do you care? You don’t write or use any software that would need this anyway, do you?