Bug 78372 - create multiple windows with offset

[Bill Spitzak]

On 05/09/2014 12:34 AM, Pekka Paalanen wrote:

>> Possibly you are reading the words "save/restore" literally, in that you
>> are imagining some blob of data stored in the compositor that is
>> recognized to restore the layout. However this is NOT what is wanted.
>
> Sure, that's the first thing comes to my mind. Let the client save a
> cookie or an encrypted blob, that it can pass back to the server when
> it creates the windows again. /handwaving/

That is what I was worried about. This will not work, as we need layouts 
that work the first time the client is run, that can be used by 
different compositors, and can port to non-Wayland systems.

> The client has no
> clue whatsoever on e.g. what positions on an output might be ok, what
> else is on the screen, or which outputs would be ok to conquer. You
> also might be on a tiling compositor, where your expectations simply
> totally fail.
>
> Your program would have to be a mind-reader to get the initial layout
> right for any user.

I have no problem with the compositor moving the windows from the 
client's expected positions. It is a *HINT*. Clients can probably assume 
that if they reuse the positions from a previous run on the same 
compositor with the same outputs, they will get the same positions. I 
think also they can assume that if a window has a smaller x value than 
another it will be further to the left. That is all I am trying to get.

I think an x/y position in some global space will fulfill these 
requirements and anything more complex is unnecessary and confusing, as 
well as making it impossible to port these positions to other operating 
systems.

I think it is acceptable that the actual client api is "output+x+y" 
along with another api that says "the x+y of the corner of each output 
is this". Then the client can do the conversion from "global" x/y to 
per-output x/y.