On Fri, Nov 25, 2011 at 09:18:52AM +0000, Thomas Adam wrote: > On Fri, Nov 25, 2011 at 12:47:06AM -0600, David Fries wrote: > > Sending a SIGTERM to FvwmButtons works to gracefully unswallow a > > program called stalonetray which is a system tray. Setting -transient > > on the FvwmButtons panel is calling XDestroyWindow and in term causes > > the programs with items in the system tray to crash with a bad window > > error. I'm removing the XDestroyWindow call and letting all transient > > Well, I suppose what's happening here is that if an application has > registered with a systray which is then killed, then it's probably defined > behaviour that those programs will die along with it, although that to me > seems buggy behaviour. I'd be much more inclined to look at what can be > done with Stalonetray. I've tried before, and so far, got no where. > > Nevertheless, the point of XDestroyWindow() here is so that we really do > unmap the window forcefully as we cannot rely on those programs we need to > get rid of coming out of a transient FvwmButton state to have the necessary > gumption to unmap their windows; I've seen a few applications like this > before -- and doing so just leaves them running in the background. Don't > forget that we're responsible as the parent of these windows.
I took another look and did some tests. DeadPipeCleanup is called atexit(). With my patch and -transient, the Swallow flag Kill is causing the X-server to close to the connection to that client, the flag Close is doing something less forcefully, but in both cases stalonetray and xclock have terminated when the button panel closes. Compared to the previous XDestroyWindow behavior where the programs in the tray are killed, the stalonetray window is destroyed (but it keeps on running because it's too stupid to exit). >From what I can tell exiting the loop normally is doing the right thing with Close and Kill, and unswallowing NoClose windows correctly. What about about adding a XDestroyWindow call at the end of DeadPipeCleanup? Would that be sufficient for forcefully destroying anything left after the other cleanup ran? > So I think I'll look in to this in more detail. I don't mind the intent of > your patch, but I do not like your approach to it -- and continual use of > isTerminated is icky and nasty in the case where we should behandling > transient FvwmButtons here much more gracefully than having many exit points > as we've now got in the code. > > So I'll rework this, and commit something over the weekend. How's that > sound? That would be great, thanks. If I knew what you were thinking I could code up the changes myself and submit another patch. -- David Fries <da...@fries.net> PGP pub CB1EE8F0 http://fries.net/~david/
