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

Implement move_to_{top,bottom} in Wayland #4629

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

QBobWatson
Copy link
Contributor

This adds move_to_top() and move_to_bottom() to Wayland windows. The bring_to_front() command had already been implemented, and these do essentially the same thing. (Before there was no command to lower a Wayland window.)

@elParaguayo
Copy link
Member

Thanks for all the pull requests!

I'm not getting involved in these, though, as they're Wayland focused so I'll leave it to the experts.

@m-col
Copy link
Member

m-col commented Dec 28, 2023

Thanks for the PR. @elParaguayo what are the differences in semantics between bring_to_front and move_to_top? Their implementations differ in the X backend.

@elParaguayo
Copy link
Member

The definitions in base.window have the same signature as these methods. However, in X11 we have an additional, optional keyword argument force. This is is used where a window is tagged as kept_above/below. Forcing disables that tag and then moves the window.

Can Wayland implement keep_above/below too?

@QBobWatson
Copy link
Contributor Author

Can Wayland implement keep_above/below too?

The analogous functionality is provided by the layer shell. This is implemented in the sense that clients can request to be placed on different layers using the layer shell protocol, but currently qtile can't place windows on a specified layer. I'd have to look through the protocol to figure out how that's supposed to work. In any case, it's beyond the scope of this PR.

@elParaguayo
Copy link
Member

That's fine. However, given the x11 backend allows the force argument to the move_to_top/bottom methods, we should allow them here so there's no config breakages between backends. We can then add the other functionality later.

@m-col @jwijenbergh any concerns with that approach?

Copy link

github-actions bot commented Apr 2, 2024

This PR is stale because it has been open 90 days with no activity. Remove the status: stale label or comment, or this will be closed in 30 days.

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

Successfully merging this pull request may close these issues.

None yet

3 participants