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.
