On Sat, Jun 24, 2006 at 10:30:38AM +0200, Bernhard R. Link wrote: > * Chris Lesniewski-Laas <[EMAIL PROTECTED]> [060623 23:51]: > > Possible fix: I've identified a line of code which seems very suspicious > > to me in src/actions.c, line 2642: > > if (!hide_bar (s) || defaults.bar_timeout > 0) show_bar (s, fmt); > > The intent of the hide_bar is to deal with the bar_timeout == 0 case, > > but it runs in either case, and I suspect there is a race condition > > between the timeout alarm and the period between hide_bar and show_bar. > > I've changed the line to: > > if ( defaults.bar_timeout > 0 || !hide_bar(s) ) show_bar( s, fmt ); > > and recompiled ratpoison. Since I've done that, I haven't been able to > > trigger the bug again, so I suspect it's fixed. > > I guess the effect of this change is that a show_bar without a hide_bar > before does not reset die alarm counter, so the bar windows vanishes > earlier.
It can't be as simple as that, because the bar window repeatedly unmaps and remaps itself when the problem shows up, and this goes on for much longer than the timeout. For what it's worth, the change I made seems to have suppressed the problem for me, though I still am not sure what causes it. The behavior is as if there is a queue of unmap-remap events that only pops every timeout. > I'm not able to reprodue it nor understand what part for > ratpoison could cause the window to reappear after the timeout. > Are you perhaps running some special program when this happens? Definitely not, that's the only hook I have on switch. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
