[PATCH] FvwmButtons transient avoid destroy

2011-11-24 Thread David Fries
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 th

Re: [PATCH] FvwmButtons transient avoid destroy

2011-11-25 Thread Thomas Adam
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

Re: [PATCH] FvwmButtons transient avoid destroy

2011-11-25 Thread David Fries
On Fri, Nov 25, 2011 at 09:18:52AM +, 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

Re: [PATCH] FvwmButtons transient avoid destroy

2011-11-25 Thread Thomas Adam
On 25 November 2011 17:53, David Fries wrote: > I took another look and did some tests.  DeadPipeCleanup is called > atexit().  With my patch and -transient, the Swallow flag Kill is The code is clear about this point. > causing the X-server to close to the connection to that client, the > flag

Re: [PATCH] FvwmButtons transient avoid destroy

2011-11-26 Thread Dominique Michel
Le Fri, 25 Nov 2011 09:18:52 +, Thomas Adam a écrit : > 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

Re: [PATCH] FvwmButtons transient avoid destroy

2011-11-26 Thread Thomas Adam
On Sat, Nov 26, 2011 at 12:37:16PM +0100, Dominique Michel wrote: > Le Fri, 25 Nov 2011 09:18:52 +, > Thomas Adam a écrit : > > > 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 stalonetra

Re: [PATCH] FvwmButtons transient avoid destroy

2011-11-26 Thread Thomas Adam
On Sat, Nov 26, 2011 at 12:37:16PM +0100, Dominique Michel wrote: > Both stalonetray and trayer will be killed and restarted during a > restart. And it work fine with compliant applications. Why? The exit handling in FvwmButtons will take care of this, and forcibly killing stalonetray or trayer i

Re: [PATCH] FvwmButtons transient avoid destroy

2011-11-26 Thread Dominique Michel
Le Sat, 26 Nov 2011 11:46:07 +, Thomas Adam a écrit : > On Sat, Nov 26, 2011 at 12:37:16PM +0100, Dominique Michel wrote: > > Both stalonetray and trayer will be killed and restarted during a > > restart. And it work fine with compliant applications. > > Why? The exit handling in FvwmButton

Re: [PATCH] FvwmButtons transient avoid destroy

2011-11-26 Thread Dominique Michel
Le Sat, 26 Nov 2011 11:42:47 +, Thomas Adam a écrit : > On Sat, Nov 26, 2011 at 12:37:16PM +0100, Dominique Michel wrote: > > Le Fri, 25 Nov 2011 09:18:52 +, > > Thomas Adam a écrit : > > > > > On Fri, Nov 25, 2011 at 12:47:06AM -0600, David Fries wrote: > > > > Sending a SIGTERM to Fvw

Re: [PATCH] FvwmButtons transient avoid destroy

2011-11-26 Thread Thomas Adam
On Sat, Nov 26, 2011 at 01:31:38PM +0100, Dominique Michel wrote: > Le Sat, 26 Nov 2011 11:46:07 +, > Thomas Adam a écrit : > > > On Sat, Nov 26, 2011 at 12:37:16PM +0100, Dominique Michel wrote: > > > Both stalonetray and trayer will be killed and restarted during a > > > restart. And it wor

Re: [PATCH] FvwmButtons transient avoid destroy

2011-12-04 Thread David Fries
On Sat, Nov 26, 2011 at 11:35:52AM +, Thomas Adam wrote: > On Fri, Nov 25, 2011 at 07:37:17PM +, Thomas Adam wrote: > > Until I look in to this in more detail, I'm perhaps more inclined to > > think the applications in question need fixing, not FvwmButtons, but > > we'll see. :) > > So th