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

Sticky window is forced to be always on top #255

Closed
HitoriSensei opened this issue Sep 17, 2019 · 8 comments
Closed

Sticky window is forced to be always on top #255

HitoriSensei opened this issue Sep 17, 2019 · 8 comments
Labels
bug Something isn't working

Comments

@HitoriSensei
Copy link

yabai -m window --toggle sticky makes window stay on all spaces but also forces window to be always on top of other windows.

Toggling float on a sticky window makes no difference.

Is this a bug or a feature?

Is there a way to make a window stay on all spaces and not always on top?

@koekeishiya
Copy link
Owner

This is intended. There is option in yabai to make this optional without editing the source code (src/window_manager.c).

@koekeishiya koekeishiya added the question Request for information or help, not an issue label Sep 17, 2019
@koekeishiya
Copy link
Owner

The fact that a sticky window will still become top-most even if window_topmost setting is disabled is something that I would consider a bug.

A sticky window however will be treated as floating implicitly, as it makes no sense for it not to be (can't be managed/tiled on multiple spaces simultaneously).

@koekeishiya koekeishiya added bug Something isn't working and removed question Request for information or help, not an issue labels Sep 17, 2019
@HitoriSensei
Copy link
Author

HitoriSensei commented Sep 17, 2019

Thank you for the response.

I've briefly checked the code in src/window_manager.c as you suggested and if I understand correctly, command yabai -m window --toggle sticky
executes void window_manager_toggle_window_sticky(struct space_manager *sm, struct window_manager *wm, struct window *window)

Assuming the window is not sticky when called, we are evaluating the following code branch:

void window_manager_toggle_window_sticky(struct space_manager *sm, struct window_manager *wm, struct window *window)
{
       ...
        struct view *view = window_manager_find_managed_window(wm, window);
        if (view) {
            space_manager_untile_window(sm, view, window);
            window_manager_remove_managed_window(wm, window->id);
            window_manager_purify_window(wm, window);
        }
        window_manager_make_sticky(window->id, true);
}

There are no conditions here for floating and none of the space_manager_untile_window, window_manager_remove_managed_window, window_manager_purify_window trigger window float.

Then the window_manager_make_sticky(window->id, true); is called:

void window_manager_make_sticky(uint32_t wid, bool sticky)
{
     if (socket_connect_un(&sockfd, g_sa_socket_file)) {
        snprintf(message, sizeof(message), "window_sticky %d %d", wid, sticky);
        socket_write(sockfd, message);
        socket_wait(sockfd);
    }
    socket_close(sockfd);

    if (socket_connect_un(&sockfd, g_sa_socket_file)) {
        snprintf(message, sizeof(message), "window_level %d %d", wid, sticky ? kCGFloatingWindowLevelKey : kCGNormalWindowLevelKey);
        socket_write(sockfd, message);
        socket_wait(sockfd);
    }
}

Am I guessing correctly that

snprintf(message, sizeof(message), "window_level %d %d", wid, sticky ? kCGFloatingWindowLevelKey : kCGNormalWindowLevelKey);

makes the window top-most?

If yes, then there is no way to prevent floating without code modification because window level parameter sticky ? kCGFloatingWindowLevelKey : kCGNormalWindowLevelKey bases only on the sticky variable.

Is setting the window_level with kCGFloatingWindowLevelKey needed for stickiness to work?

If not and if the assumptions and reasoning are correct, maybe it would be possible to add a global config option to ignore setting window level together with making it sticky?

@HitoriSensei
Copy link
Author

HitoriSensei commented Sep 17, 2019

I would also like to add that I don't use any of the awesome tiling features of yabai, I use it only to switch between spaces instantly and make windows stay on all spaces.

Since yabai also supports window floating command I would love to use the feature (I currently use Afloat to make windows top-most)

@HitoriSensei
Copy link
Author

And yes, I am setting the window_topmost to off:

yabai -m config window_topmost off

@koekeishiya
Copy link
Owner

koekeishiya commented Sep 19, 2019

Sticky windows no longer become topmost, regardless of whether or not window_topmost is enabled or not. Sticky windows will still remain floating, in that they are not tiled.

There is a new option topmost availble to the window --toggle command; e.g: yabai -m window --toggle topmost that can toggle topmost for any given window.

There is also a new option available to rules, topmost=on|off.

This should allow for greater flexibility for the user in a fairly easy-to-use way.

You can make any arbitrary window both sticky and topmost using something like the following:

# toggle sticky, topmost and resize to picture-in-picture size
alt - p : yabai -m window --toggle sticky;\
          yabai -m window --toggle topmost;\
          yabai -m window --grid 5:5:4:0:1:1

The exact same result can be achieved through a single rule as well, if automating said operation for certain windows is more appealing.

@koekeishiya koekeishiya added the addressed on master; not released Fixed upstream, but not yet released label Sep 19, 2019
@dominiklohmann
Copy link
Collaborator

The window attribute topmost is still missing I think. Haven't gotten around to testing it yet, but I don't see it anywhere in the commit. It's necessary with the toggleable attributes so you can selectively turn it on/off for windows from scripts.

@koekeishiya
Copy link
Owner

Good catch, thanks. Added to window queries as well.

koekeishiya added a commit that referenced this issue Sep 19, 2019
koekeishiya added a commit that referenced this issue Sep 19, 2019
@koekeishiya koekeishiya removed the addressed on master; not released Fixed upstream, but not yet released label Nov 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants