Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

focused vs active vs inactive #33

Closed
koekeishiya opened this issue Jun 10, 2019 · 4 comments
Closed

focused vs active vs inactive #33

koekeishiya opened this issue Jun 10, 2019 · 4 comments

Comments

@koekeishiya
Copy link
Owner

Maybe worth having the distinction of focused vs active. There can only be one focused window at a time, but with multilpe displays there can be multiple active windows, where an active window is defined to be the window that would be the focused window for that display.

@dominiklohmann
Copy link
Collaborator

Is there a specific use case outside of querying? For window queries, maybe always show both focused=0/1 and active=0/1?

@koekeishiya
Copy link
Owner Author

When window opacity is enabled it will lower the alpha of windows on external displays as they are not the focused window. This pretty much makes that functionality obsolete in multi-display environments.
There may be other situations where having this distinction would be helpful, but I have not yet thought that far ahead.

koekeishiya added a commit that referenced this issue Jun 22, 2019
@koekeishiya
Copy link
Owner Author

There is really no good way to track if a window is active or not. There are too many unpredictable ways that might screw with us. Instead of trying to track whether a window is active or not, we simply perform a bit more sophisticated checking when trying to see if the window should be "deactivated".

This will allow the active window of a display to maintain its active border color and window opacity when focus switches to a window located on a different display.

@koekeishiya
Copy link
Owner Author

koekeishiya commented Jun 22, 2019

Decided to undo these changes because it went down a path that just felt really messed up. While this is kind off annoying to me it is a more consistent behaviour - rather than trying all kinds of tricks to work around this. I think consistency in behaviour is more important at this time.

Might revisit in the future.

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

No branches or pull requests

2 participants