Re: Window stacking / raising design

2012-01-26 Thread Bill Spitzak
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

Re: Window stacking / raising design

2012-01-18 Thread Pekka Paalanen
On Tue, 17 Jan 2012 10:36:03 -0800 Bill Spitzak spit...@gmail.com 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

Re: Window stacking / raising design

2012-01-18 Thread Bill Spitzak
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

Re: Window stacking / raising design

2012-01-17 Thread Pekka Paalanen
On Mon, 16 Jan 2012 19:14:20 -0800 Bill Spitzak spit...@gmail.com 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

Re: Window stacking / raising design

2012-01-17 Thread Bill Spitzak
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