On Mon, Feb 28, 2011 at 10:02:45PM -0600, Rich Coe wrote: > Problem description: > > Using the supplied program, an application which rapidly pops up and pops > down a window, the window gets lost, such that after a popdown the > subsequent popup is lost. > > Details: > > In FVWM there was explicit code which checked during unmap if there were > subsequent events in the event queue that would cause the window to be > mapped. If true, this code would pre-empt the event queue by pulling > the event out of the queue and map the window that was being un-mapped. > This code did not work. > > Additionally, there was code in the mapping path which would check if > there were subsequent events in the event queue that would cause the > window to be unmapped. If true, this code would pre-empt te event queue > by ignoring the map request. > > As a result of the above coding scheme, the event stream would consist > of the following events in the event queue: > (0) unmap window X1 > (1) unmap window X1 > (2) map window X1 > > The first event (0) would cause the unmap handler to begin unmap > processing. The peek of the event queue would cause event (2) to be > removed from the queue and the map processing to begin. > > During map processing event (1) would cause the event to be ignored, thus > pre-empting the request for a successful unmap and re-map action, and > leaving the window in the unmap state. > > After removing the code which 'peeked' ahead and removed future events > in the queue, investigation showed that the real problem was that events > may come in for a client frame base window that no longer exists > (the client window was just unmanaged but the the client did some action > before the un-reparenting was actually done). The code confirms that this > is the case and then handles the request as if it came in as a map window > event.
Although your description seems to contradict itself in a number of places, I think the code guessing what to do with later MapRequest and UnmapNotify events is garbage. Instead, fvwm should implement either (1) code doing the detection the right way and not skip important events in the queue, or (2) live with windows popping up and down for a while. I can vaguely remember that the existing code was meant to suppress some windows that would pop up and down in an infinite loop, but I can't recall the details. > Index: ChangeLog > =================================================================== > RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v > retrieving revision 1.3137 > diff -u -3 -p -r1.3137 ChangeLog > --- ChangeLog 14 Feb 2011 21:50:53 -0000 1.3137 > +++ ChangeLog 1 Mar 2011 03:46:54 -0000 > @@ -1,3 +1,9 @@ > +2011-02-28 Rich Coe <[email protected]> > + * fvwm/add_window.c > + * fvwm/events.c > + An application which rapidly pops up and pops down a window, the window > gets lost, such that > + after a popdown the subsequent popup is lost. This has been fixed > before (and failed). Please stick to the 80 characters per line limit. > @@ -2152,13 +2152,30 @@ FvwmWindow *AddWindow( > (unsigned int*)&JunkWidth, (unsigned int*)&JunkHeight, > (unsigned int*)&JunkBW, (unsigned int*)&JunkDepth) == 0) > { > - if (Scr.bo.do_display_new_window_names) > - { > - fvwm_msg(INFO, "AddWindow", "new window disappeared"); > + /* > + * Events may come in for a client frame base window that no What is a "client frame base window" supposed to be? > + * longer exists (the client window was just unmanaged but the > + * the client did some action before the un-reparenting was > + * actually done). Confirm that this is the case and then > + * handle the request as if it came in as a root window event. > + */ > + > + w = exc->x.etrigger->xmaprequest.window; But w should already be the same as exc->w.w, so the additional check would be a null op. Also, you can not assume that the call of AddWindow() has been triggered by a MapRequest event. This can also happen when a window is recaptured, so exc->x.etrigger->xmaprequest.window would point to random data. Overall this problem requires more thinking in depth. I'd go for approach (2) if we can prevent that old problem with an orphan frame window left over from repeated MapRequest and UnmapNotify events and just wait if an endless loop of mapping/unmapping ever happens again. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
