On Fri, Feb 22, 2002 at 08:24:55PM +0100, Dominik Vogt wrote: > On Sat, Feb 09, 2002 at 02:39:48PM +0100, Olivier Chapuis wrote: > > On Wed, Feb 06, 2002 at 11:49:54PM +0100, Dominik Vogt wrote: > > > There is a bug with the ewmh code that forces windows that > > > temporarily withdraw their windows into iconic state when they map > > > again. There is a similar problem for shaded windows and possibly > > > other states too. It's easy to reproduce: > > > > > > 1) Fire up an FvwmButtons that has a panel. > > > 2) Open the panel. > > > 3) Iconify/Shade/... the panel > > > 4) Open the panel again by pressing on the panel button. > > > > > > Now, the panels should be mapped again, but instead the icon is > > > unmapped and then mapped again. I tracked that down into the > > > EWMH_GetStyle function. What FvwmButtons does is this: > > > > > > - XWithdrawWindow() > > > - set wm hints to start the window in normal state > > > - XMapWindow() > > > > > > But the code in EWMH_GetStyle() sets the do_start_iconic flag of > > > the style structure. I think there should be some EWMH_... call > > > to set the EWMH state hint around line 1502 in events.c: > > > > > > SetMapStateProp (Tmp_win, WithdrawnState); > > > > > > (or probably outside the enclosing if-clause). > > > > > > > I will take a look on this soon. > > Seems you have fixed this one. Just out of curiosity, what did > you actually do to fix it? >
In HandleUnmapNotify and HandleReparentNotify (events.c) fvwm call EWMH_RestoreInitialStates (ewmh.c) for restoring the initial ewmh hints (basically fvwm delete the ewmh hints that it sets itself when a window is unmapped or reparented). Olivier -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
