I’m working on a window switching tool for Wayland that’s kinda like Alt-Tab. However, it seems like there’s no compositor agnostic way to do things like:

  • List all currently open windows
  • Ask which window is currently focused
  • Focus a specific window

Therefore, if I want my tool to support multiple compositors, I have to re-implement this logic for each compositor.

Is the motivation security through program isolation? That doesn’t quite make sense to me since programs still can do the above things, they just have to do it compositor specifically: hyprctl clients on Hyprland, niri msg windows for Niri, etc. Also, you could just have a Wayland API that requires elevated privileges for doing these things, which the user would have to opt-in to for a specific program.

I feel like this design of Wayland causes a lot of fragmentation. There are a lot of tools that are for example Hyprland-only.

Could you please enlighten me on why Wayland has this design?

  • Chewt@beehaw.org
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    20 hours ago

    Best option right now are to use the following protocol extensions

    https://wayland.app/protocols/xdg-activation-v1 this extension covers your setting focus needs, but getting a list of other wayland clients is a bit trickier.

    https://wayland.app/protocols/ext-foreign-toplevel-list-v1 this extension can list clients in theory, but its missing support for both gnome and kde.

    Some of the unstable extensions have wide adoption, so perhaps take a look at each of them to see if they provide the functionality you want. Good luck!

    Edit: was curious and did some more digging. KDE has their own protocol extension for this https://wayland.app/protocols/kde-plasma-window-management

    As for gnome, I couldn’t find anything that seemed suitable, other than writing a gnome extension specifically to support this. I imagine that doesn’t fit within your vision for your project though.

    Anyway, I had fun looking into this. Once again good luck!