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 _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
