Pekka Paalanem thought this text that I sent was a better description of
design goals for window stacking:
* Client must make the final decision about raising. This is a
requirement so that drag & drop can be implemented, as dragging an
object must not raise the window it is in, and only the c
Bill Spitzak wrote:
Pekka Paalanen suggested I come up with a design for the Wayland
compositor to control window stacking and raising.
This is a new version of the proposal, including his ideas for full
screen atomic raise+resize:
COMPOSITOR BEHAVIOR:
The compositor never reorders surfaces
Pekka Paalanen wrote:
Unmapped surfaces never occlude anything, since they are invisible. In
your case, if you first raise W, then map B, you might see a full W,
and then B appearing on top of it. No any other surface content can
flash inside W. Is the temporary showing of full W before B appear
On Tue, 17 Jan 2012 10:36:03 -0800
Bill Spitzak wrote:
> On 01/17/2012 02:32 AM, Pekka Paalanen wrote:
>
> > I think we already have the unmapped feature. In Wayland terms:
> >
> > 1. A client creates a surface.
> > The surface is initially unmapped, and not visible.
> >
> > 2. The client se
On 01/17/2012 02:32 AM, Pekka Paalanen wrote:
I think we already have the unmapped feature. In Wayland terms:
1. A client creates a surface.
The surface is initially unmapped, and not visible.
2. The client sets the window type (role) of the surface.
Still nothing visible happe
On Mon, 16 Jan 2012 19:14:20 -0800
Bill Spitzak wrote:
> Pekka Paalanen suggested I come up with a design for the Wayland
> compositor to control window stacking and raising.
Thank you for writing down your ideas.
> I am pretty familiar with the failures of existing window management in
> thi
Pekka Paalanen suggested I come up with a design for the Wayland
compositor to control window stacking and raising.
I am pretty familiar with the failures of existing window management in
this area and would certainly like to see Wayland do this correctly, and
not copy the mistakes of the past
