51
Why isn't there a compositor agnostic Wayland API for window focusing? (lemmy.ml)
submitted 2 months ago by to c/linux@lemmy.ml
47 comments fedilink hide all child comments
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] 0 points 2 months ago (1 child)

I'm not saying KDE should do one thing or another, I understand that maintaining code, even unchanging code as you claimed, takes effort.

Yes, they're going to force me to switch to Wayland on this machine. I'm on X because I need autokey, pyautogui, and TeamViewer. I need to look into alternatives and switch, except I don't have the option of replacing TeamViewer.

I'm not really partisan in the whole X vs Wayland jihad, I run Wayland on my 2 other machines and don't notice any difference.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •