Window placement

[Pekka Paalanen]

Hi, please use reply-to-all.

On Tue, 1 Jul 2014 00:21:51 +0200
Fabrice Rey <fabounet03 at gmail.com> wrote:

> Thank you both for your constructive explanations.
> 
> > "You are thinking in X11 terms now"
> I'm afraid; still, we'll probably have to think of some similar hints as
> "skip_taskbar/skip_pager", because there will be some windows we don't want
> to see in the list of windows.

I think that may be solved by window types/roles more than having one
generic "normal window type" with flags or state for everything.

Just like a normal top-level window right now is an xdg_surface, and a
menu, combobox, etc. is an xdg_popup which is characterized by having
an input grab. xdg_surface seems to have a "flag" set with the
set_transient_for request that makes it behave differently and skip
taskbar and pager.

Whether new things would be flags for a normal top-level window or a
new window type needs to be decided on a case by case basis. We want
semantics in the protocol and policy in the compositor, rather than
just mechanisms in the protocol like X11.

> > "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?"
> well the user just positions them wherever he wants, even if it's one of
> top of the other, and then they should stay like that. Ultimately, the user
> should be able to decide where his windows are, who does the job is of no
> importance to him. I was just concerned whether it would be possible or not.

For desklets, the actual mechanism might depend on the DE. At least if
the compositor does the placement, it will not get too messed up if the
configuration of outputs changes and in many cases would be just right.
Also the DE may have its own pieces that need to arrange properly with
your desklets.

If you talking about recalling the position of any usual application
windows, that is a totally different matter.

> About the rest, I can see now where you're going; seems attractive, I just
> hope the various compositors can really handle the job.
> Do you have any detail on how it will be implemented ? like how do you
> place 2 windows of the same application ? obviously you can't rely on the
> class to distinguish both, the name may change over time, ... you're not
> even sure they will be created in the same order.
> The desklets was just an example; say I have small script that pops 4
> xterms to fill my screen, each with different options. So IIUC, contrary to
> X I can't place them where I want automatically but I can place them
> manually and the compositor will remember the positions for the next time.
> What to I need to do so that this is possible ?

You need to create a new (desktop-specific?) protocol extension, that
allows the client and the compositor to cooperate on saving and
restoring window positions, sizes, etc. No-one AFAIK has gotten to it
yet.

One idea was that the client can ask the compositor to create a
cookie (a blob) that the client can save, and when restoring the
window, give the cookie back to the compositor to recall the position
and size, subject to the compositor checking if it makes sense
(e.g. avoid putting windows in unreachable places) and adjusting as
necessary. It is a blob rather than (x,y,w,h,a,r,g,...) tuple, so that
different compositors can save all the compositor-specific data too,
like rotation angles. Also, the blob is to prevent clients from abusing
the recall mechanism to position windows in global coordinates. But
that's just one idea.


Thanks,
pq