<div dir="ltr"><div><div><div><div>Pekka I think you misunderstod my point, let me try to be more clear. </div>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. </div>How in Wayland will we be able to place this window so that its center is right on the cursor position ? </div>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. </div>In short, you press the shortkey, and then a ring of icons appear scentered on the cursor. The question is "how?" </div><div class="gmail_extra"> <div class="gmail_quote">2014-07-01 21:42 GMT+02:00 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Tue, 1 Jul 2014 20:52:28 +0200 Fabrice Rey <<a href="mailto:fabounet03@gmail.com">fabounet03@gmail.com</a>> 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 ? </div>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. <div class=""> > 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. </div>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 <div class="HOEnZb"><div class="h5"> > 2014-07-01 8:36 GMT+02:00 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>>: > > > Hi, please use reply-to-all. > > > > On Tue, 1 Jul 2014 00:21:51 +0200 > > Fabrice Rey <<a href="mailto:fabounet03@gmail.com">fabounet03@gmail.com</a>> 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. </div></div></blockquote></div> </div>