5 ms·

Under Wayland with Gnome (it's gnome-specific), I recently learned you can kill windows by using Looking Glass: // 1. Open looking glass: Alt+F2 > lg // 2.

Under Wayland with Gnome (it's gnome-specific), I recently learned you can kill windows by using Looking Glass: // 1. Open looking glass: Alt+F2 > lg // 2. Use picker to pick window (button on the top left corner). // 3. Now an object r(0) of type MetaSurfaceActor is available in the // gjs console (or some other number if you've already used it). // To get pid: r(0).get_parent().get_parent().get_meta_window().get_pid() // To kill window and process: r(0).get_parent().get_parent().get_meta_window().kill() Reference for what those .get_parent() refer to: https://gitlab.gnome.org/GNOME/mutter/-/tree/fc1de744/src/compositor https://gitlab.gnome.org/GNOME/mutter/-/tree/fc1de744/src/co...

yjftsjthsd-h 3y ago
...wait, does Wayland not have a drop in replacement for xkill?
- calvinmorrison 3y ago
  Simply jump into a Javascript runtime and run some functions from your runner! BTW your entire desktop is just an electron app rendering Wayland in WebGL.
  - deleted 3y ago
    [deleted]
- dontlaugh 3y ago
  Wayland doesn't have the kind of abstraction that would allow that, partly since it would make it very hard to guarantee perfect frame rendering. A lot of what X11 does is instead handled by Wayland "compositors", they deal with almost all such policy logic. This is largely the same situation as on Windows or macOS, which Linux desktops are finally starting to catch up to.
  - yjftsjthsd-h 3y ago
    I can't tell what level of parody we're at; if we're currently being serious, why would xkill or equivalent make rendering any harder than a normal close event?
    - dontlaugh 3y ago
      It would require that Wayland be aware of internals of the "compositor". Instead of that, Wayland is only aware of surfaces, which it can guarantee can be stitched together within a certain time budget. Hence none of the tearing that is unavoidable with X11. A window close event goes to the "compositor" of a surface, without being aware of which PID may have caused what is currently rendered on that surface. Windows and macOS do the same, if only because they have a single "compositor"/window manager.
    - calvinmorrison 3y ago
      I don't think it's parody. Wayland is just so kafkaesque not even windows know their own contents.
      - dontlaugh 3y ago
        Windows know their own contents, but Wayland doesn't. "Compositors" do know which PID has which window, though. Hence why there are "compositor"-specific alternatives to xkill.
- spellcard199 3y ago
  Some weeks ago I searched for a more general solution that doesn't depend on the compositor and doesn't need root (i.e. an xkill replacement), but I didn't find one. As a frequent user of xkill I was surprised by that too, but I remember reading somewhere that making a terminal application kill another application's window is not allowed by design. Reusing a sibling commenter's analogy, it's kind of like some javascript functions in the browser can only be triggered by user actions for security reasons. The compositor, however, is allowed to kill the windows it's showing. So if you want to kill a window, you can ask the compositor to do it for you. Gnome, KDE [0], sway [1], etc.. each expose this functionality in a way that differ between each other. [0] https://www.reddit.com/r/kde/comments/1242w2e/wkillsh_an_xkill_for_plasma_wayland/ https://www.reddit.com/r/kde/comments/1242w2e/wkillsh_an_xki... [1] https://www.reddit.com/r/linuxquestions/comments/ufw7tj/is_there_a_wayland_equivalent_for_xkill_command/ https://www.reddit.com/r/linuxquestions/comments/ufw7tj/is_t...
  - calvinmorrison 3y ago
    And eventually KDE, Gnome, and so forth will develop a shared layer on top of Wayland to handle such core functions can call them Wprops, they'll all implement the same _NET_WAYLAND_HINTS and a new group freewayland.org will come together to standardize it. Then waykill will work globally
    - yjftsjthsd-h 3y ago
      But of course by then (late 2030s) we as an industry will appreciate that Wayland has deep unfixable flaws and nobody is willing to maintain it and everyone should switch to ... V-something... let's say "Vineyard", the new graphical system that everyone agrees we should switch to ASAP because this time we got it right;)
      - Qwertious 3y ago
        In the 2030s everyone will finally acknowledge the sheer elegance of Arcan ( www.arcan-fe.com ) and admit out loud that Wayland's "just use a GUI toolkit!" was cope for Wayland being a reflexively underspecified protocol, an unfortunate result of its devs suffering from X11-PTSD.

yjftsjthsd-h 3y ago

...wait, does Wayland not have a drop in replacement for xkill?

calvinmorrison 3y ago
Simply jump into a Javascript runtime and run some functions from your runner! BTW your entire desktop is just an electron app rendering Wayland in WebGL.
- deleted 3y ago
  [deleted]
dontlaugh 3y ago
Wayland doesn't have the kind of abstraction that would allow that, partly since it would make it very hard to guarantee perfect frame rendering. A lot of what X11 does is instead handled by Wayland "compositors", they deal with almost all such policy logic. This is largely the same situation as on Windows or macOS, which Linux desktops are finally starting to catch up to.
- yjftsjthsd-h 3y ago
  I can't tell what level of parody we're at; if we're currently being serious, why would xkill or equivalent make rendering any harder than a normal close event?
  - dontlaugh 3y ago
    It would require that Wayland be aware of internals of the "compositor". Instead of that, Wayland is only aware of surfaces, which it can guarantee can be stitched together within a certain time budget. Hence none of the tearing that is unavoidable with X11. A window close event goes to the "compositor" of a surface, without being aware of which PID may have caused what is currently rendered on that surface. Windows and macOS do the same, if only because they have a single "compositor"/window manager.
  - calvinmorrison 3y ago
    I don't think it's parody. Wayland is just so kafkaesque not even windows know their own contents.
    - dontlaugh 3y ago
      Windows know their own contents, but Wayland doesn't. "Compositors" do know which PID has which window, though. Hence why there are "compositor"-specific alternatives to xkill.
spellcard199 3y ago
Some weeks ago I searched for a more general solution that doesn't depend on the compositor and doesn't need root (i.e. an xkill replacement), but I didn't find one. As a frequent user of xkill I was surprised by that too, but I remember reading somewhere that making a terminal application kill another application's window is not allowed by design. Reusing a sibling commenter's analogy, it's kind of like some javascript functions in the browser can only be triggered by user actions for security reasons. The compositor, however, is allowed to kill the windows it's showing. So if you want to kill a window, you can ask the compositor to do it for you. Gnome, KDE [0], sway [1], etc.. each expose this functionality in a way that differ between each other. [0] https://www.reddit.com/r/kde/comments/1242w2e/wkillsh_an_xkill_for_plasma_wayland/ https://www.reddit.com/r/kde/comments/1242w2e/wkillsh_an_xki... [1] https://www.reddit.com/r/linuxquestions/comments/ufw7tj/is_there_a_wayland_equivalent_for_xkill_command/ https://www.reddit.com/r/linuxquestions/comments/ufw7tj/is_t...
- calvinmorrison 3y ago
  And eventually KDE, Gnome, and so forth will develop a shared layer on top of Wayland to handle such core functions can call them Wprops, they'll all implement the same _NET_WAYLAND_HINTS and a new group freewayland.org will come together to standardize it. Then waykill will work globally
  - yjftsjthsd-h 3y ago
    But of course by then (late 2030s) we as an industry will appreciate that Wayland has deep unfixable flaws and nobody is willing to maintain it and everyone should switch to ... V-something... let's say "Vineyard", the new graphical system that everyone agrees we should switch to ASAP because this time we got it right;)
    - Qwertious 3y ago
      In the 2030s everyone will finally acknowledge the sheer elegance of Arcan ( www.arcan-fe.com ) and admit out loud that Wayland's "just use a GUI toolkit!" was cope for Wayland being a reflexively underspecified protocol, an unfortunate result of its devs suffering from X11-PTSD.