Window placement

[Bill Spitzak]

I have to disagree with a lot of this. The lack of window position is a 
HUGE problem. We need to be able to save and restore user's preferences 
for window arrangement. There is also a desire to port these window 
arrangements between Windows and Linux.

The biggest problem is that you seem to think that if a program 
specifies a window position, the compositor is *forced* to use it. That 
is not true. If the compositor has a better idea it can put the surface 
somewhere else (it should then tell the client the actual chosen 
position). I think this negates the main argument you have against 
having window positions.

The proposed intelligent window positioning has a problem: users are not 
programmers. They are going to put the windows where they want, and are 
not going to go into some ui and say "I am placing this window to the 
right of this one and making sure it is not obscured by this one". If 
you want to add the AI to the compositor to derive why they placed the 
windows as they did, go right ahead, but until that works it would be 
nice to have the xy positions.

On 06/29/2014 12:44 PM, Pekka Paalanen wrote:

> A lead idea here is, that a client tells the compositor the intent
> or purpose of the window, and the compositor then lays it out in
> the best possible way, that the app itself might never know how to
> do.

Exactly. However I propose that "the intent or purpose of the window" 
contain a "if you don't have any better idea, this xy position would be 
good".

>>> "it sounds like what you want is not for the desklet to tell the
>> compositor where it should be placed, but for the compositor to remember
>> where to place specific windows like desklets."

No this does not work. Several X11 window managers have tried this. It 
works better for the client to remember it. In particular users expect 
to be able to copy this information from one system to another but only 
for certain clients.

> Those are not just temporary effects, I can actually leave the
> windows be like that, and interact with them *correctly*. That means
> things like mouse cursor position being relayed right for each
> window, which cannot be done if using global coordinates.

Relative positioning of child windows will solve this. Clients 
attempting to use global positioning to line one window up with another 
are wrong, I agree. It may even be desirable to make this impossible: if 
a surface has a parent then the api for window position is relative to 
that parent. So it cannot be globally positioned.

> Weston also already can present one window in several places (as in
> several copies), we just do not take much advantage of that feature
> yet. Each copy of a window is roughly equivalent, they all will (if
> the compositor wants) respond to input etc.

Compositor already has to figure out what to do with move and resize in 
these cases.