[PATCH] Don't remap windows for SaveSetUnmap

[Keith Packard]

On Mon, 2008-09-22 at 11:05 -0400, Adam Jackson wrote:
> On Fri, 2008-09-19 at 17:27 -0400, Owen Taylor wrote:
> > I found that 
> > 
> >    XFixesChangeSaveSet (..., SaveSetRoot, SaveSetUnmap);
> > 
> > isn't working as expected ... when the client terminates, the save-set
> > window will be reparented to the root window, but the window manager
> > will get a MapRequest and map the window. Here's a fix to unmap the
> > window before calling ReparentWindow().
> 
> Looks right to me.  Applied, thanks!

Hmm. This doesn't quite match the intent of the XFixes change.

In the core protocol, when an unmapped window is reparented due to save
set processing, it is forcibly mapped. This makes sure that iconified
windows reappear when the window manager crashes.

The intent of the XFixes change was to allow embedded unmapped windows
to be left unmapped so that they wouldn't suddenly appear at the top
level when the application went away.

What you've done here is to make even mapped windows get unmapped when
the application terminates without destroying the embedded windows. This
doesn't match the XFixes description of the request, although does match
the (shorter) specification of the request.

I think the change is a good and reasonable one though; it does mean
that the embedded window will suddenly become unmapped when the
embedding application terminates; this change assumes that the embedded
application will be OK with this.

Can we get a change to fixesproto.txt which describes the new behaviour
so that the documentation matches the implementation? I think the X
server might also benefit from renaming the 'remap' field to something
more descriptive of the new semantics, perhaps just 'map'?

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080922/9fcd5a64/attachment.pgp>