5 ms·

Wayland does not allow clients to make decisions such as the precise placement of windows for security and sanity reasons, so I do not think that these will eve

• skeletal88 6y ago
  Then Wayland is kind of stupid. Why is that restriction needed or why do the developers think that it is a good idea to have it? For example, when the user has arranged the windows of an application in some way, and then wants to save and then restore the placement of windows, how should it be done by the application?
  • war1025 6y ago
    It's done by the window manager, which is integrated directly into Wayland. The tight coupling of the two is a semi-contentious issue.
  • 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?
  • ATsch 6y ago
    You can use positioners to request a location for your popup window relative to your toplevel window: https://wayland-book.com/xdg-shell-in-depth/popups.html https://wayland-book.com/xdg-shell-in-depth/popups.html You just don't get to set the absolute position of your window. The precise position and making sure it isn't going off of the edge of the screen is the responsibility of the compositor. This is good because it ensures proper security sandboxing and makes sure clients still work even when the windowing paradigm changes, e.g. with multiple desktops or window tiling. Developers hardcoding such assumptions is what caused much of the pain of Xorg so it's understandable that they want to make sure it does not happen again.
  • dahfizz 6y ago
    > how should it be done by the application? It shouldn't be done by the application. It's the window manager's job to manage windows. As a user, I absolutely do not want applications to be able to put themselves wherever _they_ want. The windows go where _I_ want, and the window manager gives me a single place where I can manage all that.
    • quotemstr 6y ago
      More specifically, I want to give some applications the ability to place windows where they want, warp the mouse, grab certain keys globally, snoop input, and so on. And I want to give other applications a small sandbox where they can't steal focus or hurt anything. X11 could have been evolved in this direction by sandboxing applications within little mini-universes within the existing protocol. Windows solved this problem without breaking compatibility: https://en.wikipedia.org/wiki/User_Interface_Privilege_Isolation https://en.wikipedia.org/wiki/User_Interface_Privilege_Isola... I have a fundamental philosophical disagreement with the Wayland and GNOME camp. They believe that they can enumerate all interesting use cases and that each app should fit in one of their pre-defined boxes. I'm old school and believe in making systems that provide mechanism, not policy, and that give applications the ability to do unanticipated things.
      • c487bd62 6y ago
        Why don't you propose a protocol to solve the issues you have? If it solves a problem other users have it would get adopted I'm sure (except maybe GNOME). I'm not a Wayland developer but it's what I observed in the issue tracker of my WM. A limitation is often overcome by a protocol and a basic implementation after. If you put the work in, the wlroots and KDE people are always very nice and will help you get started. https://github.com/wayland-project/wayland-protocols/tree/master/stable https://github.com/wayland-project/wayland-protocols/tree/ma... https://github.com/wayland-project/wayland-protocols/tree/master/unstable https://github.com/wayland-project/wayland-protocols/tree/ma... https://github.com/swaywm/wlr-protocols/tree/master/unstable https://github.com/swaywm/wlr-protocols/tree/master/unstable
        • 6y ago
  • nsilvestri 6y ago
    I might generally agree, but there are some very cool applications of this feature. The rhythm game Rhythm Doctor moves the window in sync with the music. [1] Surprisingly it even worked on i3wm via Wine. I would be sad if similar things couldn't be done in the future, even if they aren't enabled by default. [1] starts at 0:40 https://www.youtube.com/watch?v=5-kZ1xcxhx4 https://www.youtube.com/watch?v=5-kZ1xcxhx4)
  • geocar 6y ago
    > why do the developers think that it is a good idea to have it? Because it has little utility and a lot of risk; Baddies use this to trick people. It is also so hard to use it correctly/meaningfully in many display topologies (mostly multihead+multidpi, but also tiling, virtual desktops, etc) without querying that topology that there’s no big hurry to offer an API that users don’t want and nobody can use correctly. > For example, when the user has arranged the windows of an application in some way, and then wants to save and then restore the placement of windows, how should it be done by the application? It shouldn’t: Putting that logic into every application is bloat at best, and a lot harder than just writing down x/y coordinates and screen numbers to a file (ever had to unplug a monitor to find a window on a Mac or windows desktop? Never happens on Unix!) so it makes sense to centralise it: This is the job of the window manager and really, its only job. There are lots of window managers on Unix because users have varying needs here (I like using a lot of accessibility tools- If you could move my windows I might never find them again!)
    • saagarjha 6y ago
      > ever had to unplug a monitor to find a window on a Mac …no? I’m not sure why this would be an issue specific to those?
      • geocar 6y ago
        To those what?
• dependenttypes 6y ago
  Which is sad because I remember reading a wine developer saying that they need such a feature for menus.