position_window_absolute might not work in all window managment schemes

[i509VCB]

WLCS at the moment uses position_window_absolute to place a window somewhere in the compositor coordinate space. However this type of behavior isn't going to be supported by every type of window management solution inside the compositor.

Tilers come to mind for an example of where placing a window at an absolute position in wlcs would conflict with how window management is done.

I guess the question then is how would position_window_absolute be adjusted to handle both types of window management concepts (tiling and floating) or would some tests like pointer_movement need a tiling mode?

[wmww]

Currently the assumption that WLCS can place a surface at an arbitrary location is baked pretty deep into a lot of the tests, and it would be hard to adapt some of them to not require this assumption. WLCS is focused more towards testing flexible display server libraries (like Mir and wlroots) and less towards specific shells (like Ubuntu Frame or Sway), so we hope this isn't too much of a problem.

[AlanGriffiths]

I agree this is an issue, and would support a merging a solution if one were proposed.

In practice, this hasn't been enough of a problem to motivate anyone to find a solution.

[RAOF]

Hm. Probably the way to deal with this is to invert control? Rather than having position_window_absolute and then the tests using hard-coded positions, have a layout_of_window query that returns the window rectangle, in compositor coordinates.

That still assumes windows map to rectangles, which is an assumption but probably a fairly reasonable one.

Avoiding races would be the trick with such a solution. I agree with Alan; this is a sensible thing to want, but not something that's an urgent priority for us.