Window placement

[Pekka Paalanen]

On Tue, 1 Jul 2014 20:52:28 +0200
Fabrice Rey <fabounet03 at gmail.com> wrote:

> Here is another problem (and sorry for my numerous messages,
>  I've just though of this one now) :-)
> I have an application that pops up a menu when pressing a shortkey.
> It's a circular menu (it actually really exists such an application), so it
> should pop with its center right on the cursor.
> So here we don't need global coordinates, but to tell the compositor to
> place the window relatively to the cursor.
> Since there is only the possibility to place a window relatively to its
> parent, how would we achieve a good placement ?

The app already knows the position of the cursor on the (parent)
window, so just calculate from that. Simple.

If the cursor is not on the window, there is no position available.
In that case you'd better center that menu on the widget it is
related to. Spawning the menu completely elsewhere than where the
window is would seem confusing to me.

> By the way, we can also assume that the menu can also be a regular
> rectangular menu (depending on a parameter in its configuration), in which
> case the application may want to display its window above the cursor (like
> when you right-click on the desktop).
> This case is easy for the compositor (no constraint from the application,
> relative position = (0;0)), it's just to show that the application should
> be able to dynamically modify the relative position, with possibly any
> value.

Sorry, I don't understand what the problem here could be.

The app chooses the position of the menu surface, relative to the
parent window. If you have a pointer above that window, you also
know where the pointer is on that window. Child surfaces like menus
are positioned by x,y relative to the parent.

What we were discussing below was about positioning top-level
windows or windows that have no related parent, and so they do not
have any reference on where to position them.

Also, a client is in total control of all the child surfaces it may
use, that is, it knows all the siblings of all the surfaces it can
explicitly position. That is not the case for top-level windows, as
a client does not know about any other clients or their windows.


Thanks,
pq

> 2014-07-01 8:36 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:
> 
> > 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.