General feedback thread

[nikitabobko]

Please share your general feedback in this thread. I'm especially interested in the feedback about problems that block you from using AeroSpace on daily basis

If you have bugs to report, it'd be better to report them as a separate issue: https://github.com/nikitabobko/AeroSpace/issues/new

[axelfahy]

Great work, this looks really promising!

Currently, there is a main issue that discourages me to use it daily:

When working on multiple monitors, I find it really hard to know where my workspaces are located and end up having workspace 1 on my right monitor for example. Being able to assign workspaces to monitor would resolve this #14

[vitor-alves]

Thanks for creating this. As @axelfahy mentioned, this looks really promising.
MacOS desperately needs decent tiling window management, and this project seems to be on the right direction.
If you haven't already, I suggest you to post your project on Hacker News and Reddit. This will probably get more people interested in it.

I have been using AeroSpace for a few hours, and need to say I am impressed. You managed to recreate many i3wm core features.
I will use this as my daily driver for the following days, and will come back with feedback in a couple days.

[nikitabobko]

Thank you! I'm happy to hear it :)

If you haven't already, I suggest you to post your project on Hacker News and Reddit. This will probably get more people interested in it.

There are a few features, bugs, and todos in the code that I want to fix before making it more public. But I indeed have plans to reach out to more people once I tackle these problems

[gservat]

@nikitabobko thanks for working on this project! Looks promising. I'm a current user of Yabai and a couple of key features for me are:

1. Ability to use a CLI to switch focus to a specific space/app -- if I'm in my terminal in space 10 on monitor 2, with a shortcut defined in Alfred I want to be able to switch to, say, Slack on space 3 on monitor 1. I currently do that by using a mix of yabai -m window <window id> --focus and I programatically get the <window id> by using yabai -m query --windows, which gives me a JSON blob of all open apps across all spaces, and I can then search for the right app and fetch the window ID.

2. Assign apps to spaces -- if I open up Chrome, Slack, VS Code, Kitty, etc... Yabai is configured with "rules" so that it matches apps using regexs and puts them in the right spaces.

3. Ability to turn off window borders and reduce window border width. Nice to have though and can live without.

Any plans to support the above?

I like Yabai except that it seems to break & require some work every time a new version of OS/X comes out plus it requires SIP to be disabled for manipulation of spaces and a few other features.

[nikitabobko]

@gservat

1. Definitely needs to be supported Add CLI interface #3
2. Definitely needs to be supported Feature: assign application to workspace #15
3. The ability to change the appearance of windows (shadows, borders, titles) requires using private APIs. Using private APIs to implement features that are not practical goes against the values of the project. If someone will find a way to implement these features without using private APIs and will bring a PR, I'd be happy to consider it. But I myself certainly won't work on implementing these features.

I like Yabai except that it seems to break & require some work every time a new version of OS/X comes out

That's one of the reasons why I don't want to use private APIs :)

[barlevalon]

Super awesome! Only beta and I'm already not missing yabai/skhd. :)
One thing I noticed that can be improved and I found no mention of in the issues: fullscreen apps (macos fullscreen) take up space in aerospace containers, leaving essentially an "empty" window.

[ajkingio]

Just found this project today and am loving it! The only issue I've ran into so far is that when I try to use any of the layouts (v_accordion, h_accordion, or list) it seems to switch to a blank display. If I switch back to the display I was on the windows are still in the normal split mode.

[nikitabobko]

@barlevalon

One thing I noticed that can be improved and I found no mention of in the issues: fullscreen apps (macos fullscreen) take up space in aerospace containers, leaving essentially an "empty" window

I'm not sure what is my own opinion on whether it's a bug or a feature. At least, the current behavior preserves the window position in the layout 🤷 . But I understand that the current behavior may look like an "unpolished experience".

I personally rarely use native fullscreen windows (only for videos), so it's not a top priority for me to figure out what should be the correct behavior here. I'm happy with the current one (which I didn't program on purpose btw, it just happened as the consequence of current architecture + how macOS API works)

Nevertheless, feel free to create an issue if you have an opinion, but please elaborate on your opinion

P.S. the same problem is for hidden applications (cmd + h) and minimized windows

[nikitabobko]

@ajkingio

The only issue I've ran into so far is that when I try to use any of the layouts (v_accordion, h_accordion, or list) it seems to switch to a blank display. If I switch back to the display I was on the windows are still in the normal split mode.

I'm not sure that I understood the problem. I'd appreciate it if you could file a separate issue with steps to reproduce and expect vs actual behavior once the steps are completed

[nikitabobko]

Thanks everyone for the feedback!

The issue served its purpose, I see that this project is useful not only for me, so I close the issue