spitzak at gmail.com
Mon Jun 30 19:24:28 PDT 2014
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
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
>>> "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
More information about the wayland-devel