Stephen J. Turnbull wrote: Jered Sandner wrote: I see it with openmotif-2.1.30-4 on RedHat 6.2. I've tracked it down a bit further, and it basically boils down to the fact that the code which handles an Expose event ends up generating another Expose event. redisplay_clear_region() unmaps any subwindows in the region, which will result in the area behind the subwindows being exposed. The main evidence for this hypothesis is: 1. xmon shows continuous Unmap/Map requests for both of the clip windows (the ones called "clip-window", created in x_widget_instantiate()); one is for the progress gauge, the other for the stop button. 2. gdb shows continuous calls to unmap_subwindow() via redisplay_clear_region(). 3. If you obscure the whole of either of the two clip windows, the cycle is broken. -- Glynn Clements <glynn.clements(a)virgin.net&gt;

Glynn Clements wrote: Some more information: 1. If I rebuild using --with-widgets=athena (Motif is autodetected, so --with-dialogs=motif is implied), I see identical behaviour with an Athena progress gauge. 2. If I rebuild using both --with-widgets=athena and --with-dialogs=athena (hence no libXm dependency), the problem goes away. 3. If I revert to case 1, but make the EmacsFrame widget a subclass of Core instead of XmPrimitive, the problem goes away. Note: the progress gauge widgets are children of the EmacsManager widget (which I haven't changed), but overlap the EmacsFrame widget (as do all of the other children of the EmacsManager except the menubar). However: it also supports the comment in EmacsFrame.c: /* If we're running under Motif, make this widget a subclass of XmPrimitive. It's not clear this is necessary, but it may make focus behavior work better. */ Making the EmacsFrame a subclass of Core results in an XEmacs which only receive keystrokes when the pointer is over the EmacsFrame itself (i.e. not over a scrollbar, the menubar etc). -- Glynn Clements <glynn.clements(a)virgin.net&gt;