Window placement

Fabrice Rey fabounet03 at gmail.com
Tue Jul 1 11:10:53 PDT 2014


> "In particular users expect to be able to copy this information from one
system to another but only for certain clients."
I didn't think of it but indeed, if you save the theme of your desklet
application and restore it on another system, you expect everything ot be
the same, including the positions.
Maybe this will be possible by also copying the "blob" Pekka is talking
about, although it makes things a little inconvenient for the user.
Not to mention these "blobs" might be incompatible between compositors...



2014-07-01 4:24 GMT+02:00 Bill Spitzak <spitzak at gmail.com>:

> 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.
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140701/7aa96b99/attachment.html>


More information about the wayland-devel mailing list