> "I think that may be solved by window types/roles more than having one generic "normal window type" with flags or state for everything." It could be conceivable for desklets (they are a bit different than the regular windows, at least they seem to be on Wayland). However you can expect the casual user to build a whole extension just to place its few xterms from a script. Using some global coordinates as a hint for the compositor, as proposed by Bill, could be a good compromise.
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. > > > Thanks, > pq >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
