Feature Request: Implement list-windows --sort-by

[Perlten]

Now that we have the focus --dfs-index <index> command, it would be fantastic to extend this by allowing us to query the structure of a workspace's windows from a DFS perspective. A command like list-windows --dfs-order would be ideal for this purpose.

The output could follow the same format as the existing list-windows command, but it should be ordered as if a DFS (Depth-First Search) was performed on the workspace. See the example below.

h_tiles
├── window (index: 0)
├── v_tiles
 |      ├── window (index: 1)
 |      └── window (index: 2)
├── window (index: 3)

I realize this is similar to the functionality proposed in #16, but I believe this request is still valid. It specifically focuses on the DFS ordering of windows, disregarding how they are otherwise structured within the tree.

Checklist

• I've searched for duplicates. My search queries were (please don't forget to search in closed issues too):

  • window-list
  • tree
  • feature-request

• I've read the documentation https://nikitabobko.github.io/AeroSpace/guide & https://nikitabobko.github.io/AeroSpace/commands

• I've searched in the documentation. My search queries were:

  • window-list
  • tree

[nikitabobko]

(1) I'd prefer a different interface: aerospace list-windows --sort dfs

Because it can evolve to more options in the future:

aerospace list-windows [--sort (dfs|pid|window-id|window-title|app-name)...]...

--sort dfs should consider monitors and workspaces being part of the bigger tree. For example:

monitor 1
  workspace 1
    h_tiles
      window 1
      window 2
  workspace 2
    h_tiles
      window 3
monitor 2
  ...

(2) Feature interaction with floating windows is unclear. focus --dfs-index treats floating windows as part of the tree, but it happens only because focus command works this way in general. Until now, the focus command was the only command doing so. It's yet unclear to me whether list-windows should be a such command as well.

I think that tree command certainly won't treat floating windows as part of the tree by default. By default tree will do smth like:

workspace 1
  h_tiles
    window 1
    window 2
  floating_windows
    window 3

Now it's a question, what does list-window --sort dfs look like more: tree or focus --dfs-index?

[Perlten]

It would be logical to use the interface as --sort dfs, as it clearly aligns with the intended functionality.

As for whether floating windows should be included in the output, I believe it’s best to include them. This is primarily because the focus command also incorporates them, ensuring consistency in how both commands handle window management. But like focus a flag such as --ignore-floating could be added to facilitate both standpoints.

[nikitabobko]

After thinking about it in background for a couple of days I see no other reasonable way to sort floating windows in DFS order other than the way focus command does it

Though I realized that I'd better to rename --sort to --sort-by since it reads more nicely

But like focus a flag such as --ignore-floating could be added to facilitate both standpoints.

--ignore-floating is fine flag for focus command, but doesn't fit well for list-windows command. list-windows command should rather introduce --layout "filtering" flag #429

---

@Perlten you are certainly interested in "all things dfs" :) I'd appreciate your PR shall you decide to submit it. I'd be cool to support at least two sorting options. DFS + something else to make the flag synopsis more clear

[Perlten]

you are certainly interested in "all things dfs" :)

Who does not jump at the change to write some code that might include recursion :)

[jasonmj]

Just adding to this thread to say I'm interested. My use case would be window cycling when sorted by recently focused. Since I doubt that this is something easy to achieve from within Aerospace, I'll probably aim to get there with some external tools like Hammerspoon and Emacs. Anyhow, I look forward to seeing what comes from this thread regardless.

[alexnguyennn]

chiming in to +1:
i'd be keen to see this implemented for the usecase of enabling queries to show positional indices necessary for showing next/prev window to the currently focused or even all windows of a workspace relative to the focused one in a status bar like sketchybar (assuming the hierarchy is mapped to be compatible with --json/ --format flags too somehow).