Skip to content

Improve yabai event-based stack #14

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wants to merge 1 commit into from

Conversation

alin23
Copy link
Contributor

@alin23 alin23 commented Aug 4, 2020

Unfortunately the flicker is still there and it is caused by reacting to the window_destroyed event on Hammerspoon canvas windows.

I hope we can fix this in Hammerspoon itself by using the standard AXUnknown subrole for its windows to have them filtered out by yabai.

@AdamWagner
Copy link
Owner

Quoting from our convo on #13

About the flicker, it is caused by the window_destroyed signal which does not have an app!= filter to filter out Hammerspoon window events.

But of course, this means that closing a window leaves the stackline with a window that does not exist anymore.
Until I can think of a proper solution, I'm working around that by adjusting the yabai gap size which triggers a window_resize event and recreates the stack

Trading flicker for failing to update when a window is destroyed seems like kind of a sideways move. It could be argued that changing the focused window (and inducing flicker) is so much more common than closing/removing a window from a stack that it's worth it, but I'm not so sure. The flicker is annoying, but at least predictable.

I think I'm going to leave this one open until we figure out if #8 has legs (which will hopefully occur next weekend).

@alin23
Copy link
Contributor Author

alin23 commented Aug 7, 2020

@AdamWagner this should be automatically fixed if this yabai PR is merged: koekeishiya/yabai#636

@alin23 alin23 force-pushed the hotfix/restack-flicker branch 4 times, most recently from b89748b to e773b54 Compare August 7, 2020 11:39
@alin23 alin23 force-pushed the hotfix/restack-flicker branch from e773b54 to cc15858 Compare August 7, 2020 11:42
@alin23 alin23 changed the title Don't recreate the stack on window_destroyed to avoid flicker Improve yabai event-based stack Aug 7, 2020
alin23 added a commit to alin23/hammerspoon that referenced this pull request Aug 7, 2020
I looked through the codebase but I could not find a good reason
for having a non-standard subrole for canvas windows.

This would help yabai in [filtering out AXUnknown windows](koekeishiya/yabai#636)
and in [drawing a window stack indicator](AdamWagner/stackline#14 (comment)) that only reacts to
non-canvas windows
@alin23
Copy link
Contributor Author

alin23 commented Aug 7, 2020

Change of plans, it would be better to fix this in Hammerspoon itself: Hammerspoon/hammerspoon#2427

@alin23
Copy link
Contributor Author

alin23 commented Aug 7, 2020

@AdamWagner could you please review this again when you have some time? 😊

@AdamWagner
Copy link
Owner

Really great idea to move the yabai signals out of the readme and into a version-controlled file 👍

I see that the Hammerspoon PR is still open. So, does this mean that a user must build Hammerspoon locally to run this branch? Apologies if I'm missing something obvious…

Hammerspoon/hammerspoon#2427

@alin23
Copy link
Contributor Author

alin23 commented Aug 12, 2020

I was hoping that the yabai PR would get merged to ignore hs.canvas windows until the Hammerspoon one is merged and released.

@AdamWagner
Copy link
Owner

AdamWagner commented Aug 13, 2020

Ah gotcha. I saw the comment thread on the yabai PR, and it doesn't look like it's not going to happen any time soon. If not having this merged is making it harder for you to develop further, I'll merge it, but I don't see a reason to merge it otherwise.

@AdamWagner AdamWagner closed this Aug 22, 2020
@AdamWagner AdamWagner added this to the v0.1.60 milestone Aug 26, 2020
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants