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.
