[PATCH] Supporting pretty window destory effects in metacity-clutter

[Robert Bragg]

On Fri, 2008-10-24 at 16:19 -0400, Adam Jackson wrote:
> On Thu, 2008-10-23 at 19:14 +0100, Robert Bragg wrote:
> 
> > There is another case though where the application is forcefully closed
> > and does not control the order in which windows are destroyed. If an app
> > is killed then control moves to the server:
> > 
> > In the server:
> > CloseDownClient() ends up calling FreeClientResources() which involves
> > deleting all the windows of that client. Notably they also seem to be
> > deleted in no particular order, and that causes the same problem
> > described above.
> 
> I'm not sure offhand of the legality of the patch you gave in terms of
> the letter of the protocol, so I won't comment on that for now.  Have
> you tried adding the client's windows to the wm's save set?  That way
> they'll be preserved at connection close and you can destroy them
> yourself at your leisure (if I remember save set semantics correctly).

I don't think that will work sadly; as I understand it WM's use save
sets so that they can safely reparent other client windows onto WM owned
frames, such that, if the WM dies anything in the saveset will not get
destroyed along with the WM but instead get reparented and mapped back
on the root window.

I don't think it gives a way to let clients control window cleanup for
other client windows.

There's another similar sounding mechanism; the close mode, which can be
DestroyAll, RetainPermanent or RetainTemporary, but I think a client can
only control its own close mode.

kind regards,
- Robert