Add the yabai internal window index to the properties

[npx]

Im on OSX Monterey and wrote a status line plugin to show me the windows on the current space. No matter how I query them, the list of windows seems to be reordered, when the focus changes. Hence, I cannot determine the internal order that yabai uses when I switch through the windows.

Please expose said index, so I can render the windows in the correct order.

Alternatively, the result of the query is already a list, so I assumed that list to reflect yabai's internal order.

Thank you! (sorry for brevity, it has gotten quite late now :D)

[koekeishiya]

The list actually reflects macOS order, which is ordered by most-recently-focused. I assume what you are asking for is a list in tree-traversal order (corresponding to using the prev and next) window selectors? When using cardinal directions this traversal-order doesn't really matter though.

Also floating windows are not a part of that tree-traversal, but they should still be a part of the window set that is returned. Obviously these could be added at the end of the list.

Building such a list is quite an additional work (for the process) to do and I didn't really see much benefit originally, which is why the current version works the way it does.

[npx]

Yes I wanted to display the list that I navigate using next and prev on the screen. I have not considered floating windows in my use-case as of yet.

((Disclaimer: I am making a lot of assumptions below, as I have not (and currently cannot) look into the source.))

From your reply I assume that you are holding the tree structure and by using next and prev the nodes are directly linked.

Traversing the tree in order and assigning an index (by which I could sort the output myself) is something that would suffice for building what I need.

It would also suffice adding said index only to the output of the window query, meaning when querying windows, traverse tree once to determine the index of a window in that tree and add it to the object that is put out.

This would save on maintaining the index constantly when changes are made to the tree, but makes the query linearly a slower.

Maintaining said index on the tree nodes is more work for sure, easy to do but more work :)

What are your thoughts?

Thank you for your considerations!

PS: I assume your stack layout to be linear trees? As for stacks I would require to do the same thing, and if they are they would not require an additional effort.