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. 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? > from another FvwmButton panel, Running 'Module FvwmButtons > SystemTrayButtons' in general outside of that would just create a new > FvwmButtons, but this will do. This is by design, by the way. That won't change. > Can anyone thing of a case that XDestroyWindow is needed here? See above. -- Thomas Adam
