<div dir="ltr"><div><div><div>Here is another problem (and sorry for my numerous messages, </div> I've just though of this one now) :-) </div>I have an application that pops up a menu when pressing a shortkey. </div>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 ? 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><div class="gmail_extra"> <div class="gmail_quote">2014-07-01 8:36 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">Hi, please use reply-to-all. <div class=""> 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. </div>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. <div class=""> > > "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. </div>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. <div class=""> > 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 ? </div>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 </blockquote></div> </div>