Thank you for your reply. On Mon, Mar 26, 2012 at 10:49 AM, Thomas Adam <tho...@fvwm.org> wrote: > I think I'll just go with changing the event to check for > xdestroywindow.event and leave everything else as-is. That seems the > best approach. > But be careful - the member you want is "xdestroywindow.window", not "xdestroywindow.event". Changing to the latter will in fact not be a change at all; it refers to the same field as "xany.window".
> As far as stalonetray goes, it is very odd in its approach to managing > the tray icons -- and it's only that reason which has caused it to be > problematic, not just in FVWM but other window managers. Please note > that I do not want bugs/design flaws/whatever you choose to call them > with stalonetray, to be conflated with other problems in FvwmButtons: > that you found one very odd case where this is triggered is not > indicative of allowing stalonetray off the hook. It is fundamentally > broken. Dear me, poor stalonetray! For what it's worth, I have found that stalonetray works very well, so long as it's treated politely by FvwmButtons.