Window placement

[Fabrice Rey]

> "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 <ppaalanen at gmail.com>:

> Hi, please use reply-to-all.
>
> On Tue, 1 Jul 2014 00:21:51 +0200
> Fabrice Rey <fabounet03 at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140701/f617f684/attachment-0001.html>