Window placement

[Fabrice Rey]

Pekka I think you misunderstod my point, let me try to be more clear.
The "circular menu" is actually just a window, that paints some icons on a
ring. It doesn't have a parent window, and that's the problem.
How in Wayland will we be able to place this window so that its center is
right on the cursor position ?
We know the mouse position only relatively to a surface, but here we need
the mouse position on the screen, and then positionning the window
relatively to it.
In short, you press the shortkey, and then a ring of icons appear scentered
on the cursor. The question is "how?"


2014-07-01 21:42 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140702/505e2511/attachment-0001.html>