Window placement

[Pekka Paalanen]

Please, reply-to-all so CC's do not get dropped.

On Sun, 29 Jun 2014 19:25:04 +0200
Fabrice Rey <fabounet03 at gmail.com> wrote:

> > "Are they stacked like regular windows, where they're raised to the top
> when you click on them or are they always stacked below application
> windows? Can you alt-tab to them? Do they appear in any taskbar?"
> 
> They set the hints "skip_taskbar" and "skip_pager"; therefore their
> position on the stack is usually fixed, like always on top or on the
> opposite always below. For instance, I like to have a clock widget always
> on top and transparent to click.

You are thinking in X11 terms now. It is not certain we will have
all these in a Wayland desktop shell protocol (xdg-shell) as there
might be better Wayland style solutions to the actual use cases,
rather than just replicating X11-related APIs.

Do you want every single application to be able to screw up those
hints individually, or do you want the compositor to just do the
right thing for everything?

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.

> > "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."
> 
> Why not, that can be a solution, although it will break the behavior of the
> existing applications.
> Currently though, each time I launch some desklets under Weston they are
> placed randomly (and by randomly I mean at a different place each time,
> even out of the screen).

That is right, because they are just normal top-level application
windows. You are not telling the compostor they are desklets,
because we have no way of doing that yet.

Each DE will cook up its own way, and if a common standard emerges,
it emerges and allows "DE-agnostic" desklets. This way every DE can
do what is right for them rather than being restricted by some
designed-by-committee protocol mandated from above.

We are not simply copying all mechanisms like global coordinates
from X11, because we want to do better: let the compositor be in
charge, have interactions be well defined, avoid glitches, etc.

> By the way they don't need to be aware of the current transformation
> matrix, nor if the Exposé view is active or not. Of course, the interesting
> parameter here is the position on the desktop at a normal time.
> The compositor places them wherever it wants, like with any window.
> Really, just like it works now with any WM that have some desktop effects
> (so almost all).

http://people.collabora.com/~pq/menu-rotate.png
http://people.collabora.com/~pq/rotate3d-pixman-more.png

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.

If we had any global coordinates in the protocol, that would be
practically impossible. (While the screenshots above are using
2D-projective matrices, nothing prevents you from doing completely
non-linear transformations, and everything will still work right
without any fixing in apps.)

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.

In all these cases, at least I would have great difficulty in
defining what "window position" even means. There is no "normal
time" vs. "not normal time".

> Now, I see your point, but will the compositor really be able to place them
> correctly ?

The compositor will have *much* better chances than the app: the
compositor will know about all windows, an app only knows about its
very own windows and _nothing_ else. IOW it will be very difficult
for the app to e.g. avoid obscuring or being obscured by some other
window, if it manipulates its global position.

> Say I positionned a desklet to be on the bottom-right corner of the screen;
> each time the resolution is changed, the desklet can reposition itself
> accordingly to stay in the corner. How will the compositor fill the same
> role ? I'm afraid when the resolution goes higher, it will just let the
> desklet at its current position, which will become somewhere on the screen.

No. The compositor is changing the resolution, the compositor can
move any window at any time. It will Just Work. Even better, when
the resolution is changed, the desklet will be immediately in the
correct new position. No glitches, no jumping after the fact.

Btw. what if you start two desklets? Both go in the same corner? On
top of each other? Do you need to manually configure each desklet
to go in a different corner?

> About letting know the position, which is in my opinion more important,
> because I can't see a workaround like for the previous feature: I don't
> think adding the position in the Configure events would complicate things
> (the application that doesn't need it can just ignore it).

See all above. It is a very deliberate decision to not include
global position in the protocol, and we have worked hard on that.

> It also doesn't add a new event to the API, and all toolkits already
> provide the (wrong) information anyway. As a developper, I find this lack
> of information quite inconvenient.

You have to start thinking in a new way. The compositor is no
longer under the mercy of every single app like in X11. In this
new world, the compositor decides.

First, figure out what the use case is. An application does not
want to "put this window at 100,150 always-on-top not-focuseable".
Rather, the application wants to, say, show a clock widget on the
side of the workspace for instance. Then you start figuring out
what information does the compositor need to make that window
interact with all the other windows and the desktop space properly,
and that leads to a protocol extension definition. If the extension
is good, generic and re-usable, then it might suit more than one DE,
at which point it may become a desktop standard.


Thanks,
pq