<div dir="ltr"><div><div><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."<br></div>It could be conceivable for desklets (they are a bit different than the regular windows, at least they seem to be on Wayland).<br>
</div>However you can expect the casual user to build a whole extension just to place its few xterms from a script.<br></div>Using some global coordinates as a hint for the compositor, as proposed by Bill, could be a good compromise.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-01 8:36 GMT+02:00 Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi, please use reply-to-all.<br>
<div class=""><br>
On Tue, 1 Jul 2014 00:21:51 +0200<br>
Fabrice Rey <<a href="mailto:fabounet03@gmail.com">fabounet03@gmail.com</a>> wrote:<br>
<br>
> Thank you both for your constructive explanations.<br>
><br>
> > "You are thinking in X11 terms now"<br>
> I'm afraid; still, we'll probably have to think of some similar hints as<br>
> "skip_taskbar/skip_pager", because there will be some windows we don't want<br>
> to see in the list of windows.<br>
<br>
</div>I think that may be solved by window types/roles more than having one<br>
generic "normal window type" with flags or state for everything.<br>
<br>
Just like a normal top-level window right now is an xdg_surface, and a<br>
menu, combobox, etc. is an xdg_popup which is characterized by having<br>
an input grab. xdg_surface seems to have a "flag" set with the<br>
set_transient_for request that makes it behave differently and skip<br>
taskbar and pager.<br>
<br>
Whether new things would be flags for a normal top-level window or a<br>
new window type needs to be decided on a case by case basis. We want<br>
semantics in the protocol and policy in the compositor, rather than<br>
just mechanisms in the protocol like X11.<br>
<div class=""><br>
> > "Btw. what if you start two desklets? Both go in the same corner? On<br>
> top of each other? Do you need to manually configure each desklet<br>
> to go in a different corner?"<br>
> well the user just positions them wherever he wants, even if it's one of<br>
> top of the other, and then they should stay like that. Ultimately, the user<br>
> should be able to decide where his windows are, who does the job is of no<br>
> importance to him. I was just concerned whether it would be possible or not.<br>
<br>
</div>For desklets, the actual mechanism might depend on the DE. At least if<br>
the compositor does the placement, it will not get too messed up if the<br>
configuration of outputs changes and in many cases would be just right.<br>
Also the DE may have its own pieces that need to arrange properly with<br>
your desklets.<br>
<br>
If you talking about recalling the position of any usual application<br>
windows, that is a totally different matter.<br>
<div class=""><br>
> About the rest, I can see now where you're going; seems attractive, I just<br>
> hope the various compositors can really handle the job.<br>
> Do you have any detail on how it will be implemented ? like how do you<br>
> place 2 windows of the same application ? obviously you can't rely on the<br>
> class to distinguish both, the name may change over time, ... you're not<br>
> even sure they will be created in the same order.<br>
> The desklets was just an example; say I have small script that pops 4<br>
> xterms to fill my screen, each with different options. So IIUC, contrary to<br>
> X I can't place them where I want automatically but I can place them<br>
> manually and the compositor will remember the positions for the next time.<br>
> What to I need to do so that this is possible ?<br>
<br>
</div>You need to create a new (desktop-specific?) protocol extension, that<br>
allows the client and the compositor to cooperate on saving and<br>
restoring window positions, sizes, etc. No-one AFAIK has gotten to it<br>
yet.<br>
<br>
One idea was that the client can ask the compositor to create a<br>
cookie (a blob) that the client can save, and when restoring the<br>
window, give the cookie back to the compositor to recall the position<br>
and size, subject to the compositor checking if it makes sense<br>
(e.g. avoid putting windows in unreachable places) and adjusting as<br>
necessary. It is a blob rather than (x,y,w,h,a,r,g,...) tuple, so that<br>
different compositors can save all the compositor-specific data too,<br>
like rotation angles. Also, the blob is to prevent clients from abusing<br>
the recall mechanism to position windows in global coordinates. But<br>
that's just one idea.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div>