Skip to content

Add --sort tree-order flag to list-windows command#1839

Closed
prawwtocol wants to merge 1 commit intonikitabobko:mainfrom
prawwtocol:feature/list-windows-sort
Closed

Add --sort tree-order flag to list-windows command#1839
prawwtocol wants to merge 1 commit intonikitabobko:mainfrom
prawwtocol:feature/list-windows-sort

Conversation

@prawwtocol
Copy link

@prawwtocol prawwtocol commented Dec 3, 2025

PR checklist

  • Explain your changes in the relevant commit messages rather than in the PR description. The PR description must not contain more information than the commit messages (except for images and other media).
  • Each commit must explain what/why/how and motivation in its description. https://cbea.ms/git-commit/
  • Don't forget to link the appropriate issues/discussions in commit messages (if applicable).
  • Each commit must be an atomic change (a PR may contain several commits). Don't introduce new functional changes together with refactorings in the same commit.
  • The GitHub Actions CI must pass (you can fix failures after submitting a PR).

Failure to follow the checklist with no apparent reasons will result in silent PR rejection.

@prawwtocol prawwtocol force-pushed the feature/list-windows-sort branch from 67b7aab to af80dba Compare December 3, 2025 20:33
Introduce a new --sort flag for the list-windows command to control
the order in which windows are displayed. This addresses the need for
different sorting strategies depending on the use case.

What changed:
- Added --sort flag with two possible values:
  * tree-order (new default): Windows are listed in tree traversal
    order (DFS), matching their visual order in accordion/tiles layout
  * app-name: Windows sorted alphabetically by application name,
    then by window title (previous default behavior)

Why:
The tree-order sorting provides a more intuitive output that matches
the visual representation of windows in the workspace tree. This is
particularly useful when debugging or inspecting window arrangements,
as the list order corresponds to the actual layout order.

How:
- Added SortOrder enum to ListWindowsCmdArgs with tree-order and
  app-name variants
- Modified ListWindowsCommand to apply sorting based on the flag
- tree-order leverages existing allLeafWindowsRecursive traversal
- Updated documentation and generated help text to reflect the new flag

Breaking change: Default sorting changed from app-name to tree-order.
Users who rely on alphabetical sorting should explicitly use
--sort app-name flag.
+
Possible values: +
+
. `tree-order` - (default) Windows are listed in tree traversal order (DFS). This matches the visual order in accordion/tiles layout.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you think that tree-order is a better default? (It's a genuine question)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I failed to address this in my comment notes but one of the usecases is better integration with window bar applications like

https://github.com/Jean-Tinland/simple-bar
https://github.com/cmacrae/spacebar?tab=readme-ov-file
https://github.com/FelixKratz/SketchyBar

They benefit from displaying open windows in tree-order instead of id-sorted order

Copy link
Author

@prawwtocol prawwtocol Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will include that info in further commit descriptions

@@ -1 +1 @@
6.2.1
6.2.1 No newline at end of file
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't touch unrelated files for no reasons

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

weird thing my editor did. you're right. sorry!

also, my PR wasnt ready for review when you left these comments, I would've caught some of these (and have fixed the CI already) as not to waste your time. I will mark the PR as draft in the future

"--app-bundle-id": singleValueSubArgParser(\.filteringOptions.appIdFilter, "<app-bundle-id>") { $0 },

// Sorting flag
"--sort": singleValueSubArgParser(\._sortOrder, "<sort-order>") { SortOrder(rawValue: $0) },
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--sort flag should conflict with --count flag

@@ -49,7 +49,14 @@ struct ListWindowsCommand: Command {
_list.append((window, try await window.title))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please link the appropriate issue in the commit message: #491

Copy link
Author

@prawwtocol prawwtocol Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for creating an issue for me! will do

upd: didn't see this issue when I created my PR. just needed this functionality myself lol!

"--app-bundle-id": singleValueSubArgParser(\.filteringOptions.appIdFilter, "<app-bundle-id>") { $0 },

// Sorting flag
"--sort": singleValueSubArgParser(\._sortOrder, "<sort-order>") { SortOrder(rawValue: $0) },
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to call the flag --sort-by

Comment on lines +42 to +43
public var _sortOrder: SortOrder? = nil
public var sortOrder: SortOrder { _sortOrder ?? .treeOrder }
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public var _sortOrder: SortOrder? = nil
public var sortOrder: SortOrder { _sortOrder ?? .treeOrder }
public var sortOrder: SortOrder = .treeOrder

The second variable seems redundant

"--app-bundle-id": singleValueSubArgParser(\.filteringOptions.appIdFilter, "<app-bundle-id>") { $0 },

// Sorting flag
"--sort": singleValueSubArgParser(\._sortOrder, "<sort-order>") { SortOrder(rawValue: $0) },
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use parseEnum util function as it produces nicer error message in case of parsing error

[--sort <sort-order>] [--format <output-format>]
[--count] [--json]
aerospace list-windows [-h|--help] --all [--format <output-format>] [--count] [--json]
aerospace list-windows [-h|--help] --all [--sort <sort-order>] [--format <output-format>] [--count] [--json]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also update grammar/commands-bnf-grammar.txt

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for your insightful comments! You know much more about this project than me, of course 🤗

"--app-bundle-id": singleValueSubArgParser(\.filteringOptions.appIdFilter, "<app-bundle-id>") { $0 },

// Sorting flag
"--sort": singleValueSubArgParser(\._sortOrder, "<sort-order>") { SortOrder(rawValue: $0) },
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to --workspace and --monitor, <sort-order> should be not a scalar value but a space-separated array. Otherwise, the current .sortedBy([{ $0.window.app.name ?? "" }, \.title]) sorting is not representable

Right now, you call it app-name, but it's just wrong. The flag that represents the current default sorting should be --sort-by app-name window-title

@prawwtocol prawwtocol force-pushed the feature/list-windows-sort branch from af80dba to 06561bb Compare December 4, 2025 07:27
@nikitabobko
Copy link
Owner

Closing due to inactivity. Feel free to open a new PR

also, my PR wasnt ready for review when you left these comments, I would've caught some of these (and have fixed the CI already) as not to waste your time. I will mark the PR as draft in the future

Please refrain from opening PRs (even drafts) until you expect to receive any input

@kim-raaschou
Copy link

Follow-up PR continuing this work: #1918

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants