WIP: Wayland z layering #4857
WIP: Wayland z layering #4857
Conversation
This took me a while to figure out. If the window is still pending, placing it after this configure will result in wlroots' visibility checks to be confused. This probably is because the window has not committed a buffer. Let's only do the configure workaround if the window is pending and remove the place afterwards. In english: with wayland z-layering and without this patch, if floats_kept_above is enabled, an xwayland window that is under a floating one will be invisible. Even if only parts of the window is hidden by the floating one.
3245b55
to
332890a
Compare
libqtile/backend/wayland/core.py
Outdated
| SceneTree.create( | ||
| self.windows_tree | ||
| ), # Keep above windows (floats go here if floats_kept_above |
There was a problem hiding this comment.
holy crap black is ugly
332890a
to
279ec65
Compare
| self.bring_to_front() | ||
| self.move_up() |
There was a problem hiding this comment.
@elParaguayo is this correct?
There was a problem hiding this comment.
I am confused what needs to happen when above is set in place
There was a problem hiding this comment.
I think move_up is ok here - but let's see what happens in the tests ;)
| if force and self.tree_layer is self.core.keep_below_window_tree: | ||
| self.reparent(self.get_new_layer(self._float_state)) |
There was a problem hiding this comment.
@elParaguayo does move_up or down with force also remove it from bring_to_front layer?
There was a problem hiding this comment.
x11 doesn't have a bring_to_front layer. In x11, bring_to_front ignores layers and brings the window to the front. Once it loses focus, it should be restacked according to its layer.
The behaviour of force is as follows. If this is True, move_up will move the window out of the kept_below layer group, and move_down will move the window out of the kept_above layer group. If False, the windows can only move within their respective layer groups.
279ec65
to
6ab2803
Compare
| # TODO: is this correct | ||
| self.bring_to_front() |
There was a problem hiding this comment.
I have to check all bring to front calls in the wayland code base
6ab2803
to
39f7334
Compare
39f7334
to
5d03d42
Compare
| if force and self.tree_layer is self.core.keep_below_window_tree: | ||
| self.reparent(self.get_new_layer(self._float_state)) |
There was a problem hiding this comment.
x11 doesn't have a bring_to_front layer. In x11, bring_to_front ignores layers and brings the window to the front. Once it loses focus, it should be restacked according to its layer.
The behaviour of force is as follows. If this is True, move_up will move the window out of the kept_below layer group, and move_down will move the window out of the kept_above layer group. If False, the windows can only move within their respective layer groups.
| def keep_below(self) -> None: | ||
| self.reparent(self.core.keep_below_window_tree) | ||
|
|
||
| @expose_command() | ||
| def keep_above(self) -> None: | ||
| self.reparent(self.core.keep_above_window_tree) |
There was a problem hiding this comment.
In X11, we have a kept_above/below property. We should add that here.
In addition, the X11 method signature includes an enable argument. If this is set, then kept_above/below is set to that value. If it's None then the state is toggled.
| self.bring_to_front() | ||
| self.move_up() |
There was a problem hiding this comment.
I think move_up is ok here - but let's see what happens in the tests ;)
|
This PR is stale because it has been open 90 days with no activity. Remove the |
Some TODOs here and there, just want this PRed now so people can test.
Also tests still TODO of course