Thanks for the reply.

On Sat, Mar 24, 2012 at 2:32 PM, Thomas Adam <tho...@fvwm.org> wrote:
>
> On 21 March 2012 22:06, Robert Parlett <r.parl...@gmail.com> wrote:
> > There are two possible fixes.  I am not sure which is best.  The first
> > and most obvious is to change the "Event.xany.window" at line 1461
> > above to "Event.xdestroywindow.window".  Note that there are also two
>
> Ah, but this isn't guaranteed to be the correct window...

Can you elucidate a bit... surely the correct window (to compare with
swin) at line 1461 is the one being destroyed.  At the moment, as the
code stands, that is not necessarily what is being compared.
Event.xany.window will refer to the destroyed window if the event was
selected via StructureNotifyMask (as it will be if the swallowed
window itself is destroyed), but it will refer to the *parent* of the
destroyed window if the event was selected via SubstructureNotifyMask
(as it will be if a child of the swallowed window is destroyed).  This
second case is what happens when a stalonetray icon is destroyed.  The
parent of the destroyed window is the swallowed window itself, which
is why the the "Event.xany.window == swin" test succeeds and makes
FvwmButtons wrongly conclude that the tray is destroyed whenever a
tray icon is destroyed.

The correct test is "Event.xdestroywindow.window == swin", since
"Event.xdestroywindow.window" always refers to the destroyed window,
regardless of whether the event was selected via StructureNotifyMask
or SubstructureNotifyMask

The naming of the fields in the overlapping structs XAnyEvent and
XDestroyWindowEvent is highly misleading, and I can easily see how one
could write "Event.xany.window", thinking you were getting
"Event.xdestroywindow.window", but in fact were getting
"Event.xdestroywindow.event".

>
> I reported this to the author of stalonetray well over a year ago.
>

I must say I thought that stalonetray was at fault too, but in the
event concluded it wasn't.  The misbehaviour of stalonetray in
Fvwmbuttons is triggered by one of its icons closing, which in turn
sends the DestroyNotify to FvwmButtons, which misinterpets the
message, believing that the tray itself has been destroyed.  I didn't
mention it in my original bug report (which was a bit too long
anyway!), but you will see other odd stalonetray behaviour as a
consequence, in particular when it tries to expand its tray window.
If this happends after the bug has been triggered, then the tray will
disappear.

> I guess the reason why FvwmButtons tracks StructureNotify requests is
> so that it can track windows changing map state -- consider
> iconification a good example of this.  Perhaps the behaviour of
> FvwmButtons from transitioning from Goodstuff might have repositioned
> itself based on the client bit-gravity?  I am not sure.  But I can
> certainly see a need for it still -- Tk applications have
> traditionally never played well with reparenting.
>

I am sure you're right, and that StructureNotify events for swallowed
windows must be tracked.  What I was suggesting (somewhat
speculatively) was getting rid of SubstructureNotifyMask from
SW_EVENTS, but leaving StructureNotifyMask.  In other words,
FvwmButtons will get the StructureNotify events for the swallowed
window itself, but not for the swallowed window's children.  So in the
case of stalonetray, FvwmButtons won't even get notified when a tray
icon is destroyed, and the whole question of interpreting or
misinterpreting that event no longer arises.  Of course the
speculative element here is that some other feature of FvwmButtons
relies on being notified about what is happening to a swallowed
window's children, but I can't think what that could be.

Reply via email to