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.

Reply via email to