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
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