Include ext-foreign-toplvel-list identifiers in GET_TREE output

[tmccombs]

This would allow doing things like selecting a toplevel using a dmenu-like selector, then passing it to another process to do something with that window, such as passing it grim to take a screenshot of a window, or using it as a chooser for xdg-desktop-portal-wlr for screencasting (see emersion/xdg-desktop-portal-wlr#107 (comment)).

[emersion]

Hm, not sure I'm following. Why not grab the toplevel list via the Wayland protocol rather than the Sway IPC? That way it's not specific to Sway?

[tmccombs]

A couple of reasons.

First of all, getting a list of windows from a wayland protocol is out of scope for a program like bemenu or tofi, so being able to get this info from swaymsg would be convenient. Although, I suppose you could create a separate program for this.

Another reason is that the sway ipc provides more information than the toplevel protocol. So, for example if I wanted to use something like slurp to select a window, I could get a point from slurp, then look up which view that point is, using the geometry information from the sway ipc, then pass the foreign toplevel identifier to a screenshot or screencast tool. In some cases you might be able to associate the view with a toplevel identifier based on the app_id and title, but what if those aren't unique?

[emersion]

For the first use-caae there is e.g. https://git.sr.ht/~leon_plickat/lswt

For the second use-case that sounds like a good idea but note that with this method users won't be able to select windows on other workspaces or otherwise hidden.

[Ferdi265]

For the second use-case that sounds like a good idea but note that with this method users won't be able to select windows on other workspaces or otherwise hidden.

For use-cases where you just want a list of all possible toplevels you don't usually need window coordinates, but if you want to visually select them with something like slurp, you would only need currently visible windows anyway, so IMO the solution with doing it in get_tree makes sense to me, and being possible to link information from that to a standard Wayland foreign toplevel identifier is useful.