Subject: Re: to do for 2.4 (update 8)

From: Dominik Vogt <[email-masked]>
Date: Thu, 8 Jul 1999 01:26:35 +0200

On Wed, Jun 30, 1999 at 10:32:51PM -0400, Paul D. Smith wrote:
> %% Dominik Vogt <[email-masked]> writes:
> 
>   dv> You said you would elaborate on this and I was hoping for more
>   dv> information before trying to reproduce it again.
> 
> Sorry; I made another post that elaborated more but maybe I wasn't
> clear.
> 
> I've done some more testing, this time on my Linux box at home, and it's
> trivial for me to reproduce.
> 
> Start an Emacs 20.3 in X mode.  Use C-x 5 2 to create a new frame.
> Iconify the new frame.
> 
> Now run the Iconify-and-Compact function:
> 
>   AddToFunc Iconify-and-Compact
>   +       "C" Iconify
>   +       "C" All (CurrentDesk Iconic) RecaptureWindow
> 
> Note!  A normal "Recapture" command works OK!  You need to use (I
> suppose) RecaptureWindow.
> 
> Now if you deiconify the Emacs frame with the mouse, it works OK.  But,
> if you use the Buffers->Frames menu to pick it and have Emacs deiconify
> it instead, it doesn't work (the first time).
> 
> When I do it, the frame appears (along with FvwmAnimate animation) and
> the icon disappears.  However, _only_ the frame appears, the contents of
> the frame are never mapped.  Further, I can't give this frame focus or
> bring it to the front.  I can, though, resize it and move it via the
> border; the interior of the frame is just a copy of whatever was on the
> screen when it was created.
> 
> If I use the Buffers menu to ask for the frame _again_, the icon briefly
> appears, the deiconify animation appears, _then_ the frame contents are
> mapped correctly and the frame works fine.  You can iconify this frame
> again and again and observe exactly the same behavior.  It's not until
> you actually delete the frame (with C-x 5 0 or whatever) that it will
> stop.

Yes, I can confirm that. Emacs sends *two* MapRequest events to fvwm
when de-iconifying itself. The first is interpreted correctly (indeed
you may have noticed the frame flashing for a moment), but the second
screws up the internal state in the dreaded 'isIconicState' global
variable :( I have made a fix to reset it after a MapRequest. This
should solve the problem (at least it does for me).

> I just had another odd thing happen; after a recapture I couldn't send
> my Emacs frame to the back anymore.  I'll try to clarify this one.

That seems to be the bug with raising/lowering we are hunting for
a while now. Unfortunately I have not seen it again after the first
two appearances. If you see it again, could you try to debug the
running fvwm then? (e.g. by starting fvwm on a second X server on
a different display). Any information on how to reliably reproduce
it is badly needed.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 08 Jul 1999 02:20:11 -0400

dv> Yes, I can confirm that. Emacs sends *two* MapRequest events to fvwm
  dv> when de-iconifying itself. The first is interpreted correctly (indeed
  dv> you may have noticed the frame flashing for a moment), but the second
  dv> screws up the internal state in the dreaded 'isIconicState' global
  dv> variable :( I have made a fix to reset it after a MapRequest. This
  dv> should solve the problem (at least it does for me).

OK, I confirm the latest CVS fixes this problem.

  >> my Emacs frame to the back anymore.  I'll try to clarify this one.

  dv> That seems to be the bug with raising/lowering we are hunting for
  dv> a while now. Unfortunately I have not seen it again after the first
  dv> two appearances. If you see it again, could you try to debug the
  dv> running fvwm then? (e.g. by starting fvwm on a second X server on
  dv> a different display). Any information on how to reliably reproduce
  dv> it is badly needed.

Actually, instead it appears to be the same problem Dan (?) reported,
where RaiseLower doesn't work if windows are partially off-screen.  I
can RaiseLower fine as long as Emacs is fully on-screen.  I think the
"sliding Emacs frame" problem we already discussed (a bug in Emacs
apparently) caused the frame to scoot over past the right side of the
screen; then I couldn't RaiseLower it anymore.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 8 Jul 1999 12:43:53 +0200

> a different display). Any information on how to reliably reproduce

If all else fails, we could hack a "stack-dump" function into
fvwm to request a complete listing of the stacking order when the
problem occurs.

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 8 Jul 1999 21:30:28 +0200

> fvwm to request a complete listing of the stacking order when the

That should really help debugging this evil problem. Could you
write something, Matthias?

Bye

Dominik ^_^