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 <[email protected]>: > On Tue, 1 Jul 2014 20:52:28 +0200 > Fabrice Rey <[email protected]> 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 <[email protected]>: > > > > > Hi, please use reply-to-all. > > > > > > On Tue, 1 Jul 2014 00:21:51 +0200 > > > Fabrice Rey <[email protected]> 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. >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
