Subject: FvwmButtons panel tests

From: Dan Espen <[email-masked]>
Date: Tue, 13 Mar 2001 14:30:33 -0500

I think I've pretty well covered the FvwmButtons panel logic.
These are the remaining issues:

1. When I ask for an animation with 1 step, the window doesn't appear.

2. In test 3, I tried placing windows relative to the module.  One of
the 2 upper corner panels doesn't seem to be placed correctly.
I placed the one on the left at "Module top - window_width"
and the one on the right at "Module top + window_width".
One is near the module corner and the other isn't.

3. In test 3, the bottom row panels seem to first appear somewhere
inside the Module, then move to the edge and animate.  Sliding in
works fine.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Wed, 14 Mar 2001 03:36:44 +0100

> 1. When I ask for an animation with 1 step, the window doesn't appear.

I don't see this problem here.

> One is near the module corner and the other isn't.

I think this is correct. The panel appears indeed one panel
width right from the left side of the module window, just as you
requested.  I guess you wanted to specify "Module top +module
width" not "+window width".  The correct spec is

  Module top 100 0

> inside the Module, then move to the edge and animate.  Sliding in

That was actually a bug in fvwm's ConfigureReuquest handler.  If
an application called XMoveResizeWindow() but did not change the
x/y coordinates, only the size, fvwm treated this as if it had
simply called XResizeWindow().  This is not quite correct.  If
a window with SouthEast gravity is resized, , the top left corner
moves, but should not if the window was told with XMRW() to stay
in place.

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: Dominik Vogt <[email-masked]>
Date: Wed, 14 Mar 2001 04:11:00 +0100

I just noticed these comments in the test script:

  # Root right 0 50 put brl down a page in the middle. isn't that 100?
  # This goes to the bottom right.  why?
  FC '*FButt: (Panel(left,  '"$base"' Root right 0 0) brl "W brl")'

  # This ends up on the left bottom, -10p off screen, 20p up from the bottom
  FC '*FButt: (Panel(right, '"$base"' Root right -5p -100p) brr "W brr")'

The reason why this works unexpected is: for left/right sliding
direction, the left/right panel position is not legal, according
to the man page.  Only top/bottom are allowed.  However, the
parsing code simply treast top exactly the same as left and bottom
exactly the same as right.  Instead it should issue an error
message.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 14 Mar 2001 07:46:31 -0500

> I don't see this problem here.

Still fails for me.

I just tried again.  When I click the button, I don't see anything.
I just moved a window over the area where the panel should be, I have
an area of the screen that doesn't refresh, parts of the window I moved
over the area are left behind.  I tried using rxvt instead of xterm,
same problem.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 14 Mar 2001 14:14:28 +0100

> over the area are left behind.  I tried using rxvt instead of xterm,

Hm.  Could you debug FvwmButtons?  I guess it's best to set a
breakpoint into the SlideWindow() function in libs/WinMagic.c
and then single step through the loop and see what happens.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Wed, 14 Mar 2001 02:50:25 +0100

> 1. When I ask for an animation with 1 step, the window doesn't appear.

This works perfectly for me.

> One is near the module corner and the other isn't.

This looks correct to me. You probably wanted to place the top
right panel at "Module left + Module width" not at
"Module left + Window width".  The calculations always seem to be
relative to the left side of the window.  Could you check if that
matches the documentation?

> inside the Module, then move to the edge and animate.  Sliding in

I'll fix that one.

4. In the first test, the panel of the top right button has no
fvwm window decorations for me.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 15 Mar 2001 18:08:22 +0100

> fvwm window decorations for me.

Argh, just ignore this message.  I thought I didn't send it.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 15 Mar 2001 19:39:14 -0500

> and then single step through the loop and see what happens.

Hmm, any hints on what to look for?

I see it go thru SlideWindow and it calls

XMoveResizeWindow(dpy, win, x, y, g_w, g_h);
XMapWindow(dpy, win);
XMapSubwindows(dpy, win);
XMoveResizeWindow(dpy, win, x, y, w, h);

In that order.

The geometry args look OK on the MoveResize calls.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 16 Mar 2001 10:51:39 +0100

> The geometry args look OK on the MoveResize calls.
 
And the window still does not appear?  What happens if you add an
XSynchronize() call?

Can you see the window in the output of "xwininfo -root -tree"?

Is the HandleMapRequest() function in events.c ever called?

It might help to run fvwm in an XNest or on a second X server and
single step it in a second debugger.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sat, 17 Mar 2001 19:57:38 -0500

Dominik Vogt <[email-masked]> writes:
> And the window still does not appear?

Right, no window appears.

> What happens if you add an
> XSynchronize() call?

The same thing happens.  After I added that, I could then see
that the indicator seems to be redrawn twice after an animation.

> Can you see the window in the output of "xwininfo -root -tree"?

Yes.  In fact, if I click on the area of the screen where the window
is supposed to be, xwininfo prints the information for the window.

> Is the HandleMapRequest() function in events.c ever called?

Yes it is.

> single step it in a second debugger.

I can single step it but it seems to do everything right except
make the window visible.  Right now, I'm only able to try this
with Exceed.  Perhaps fvwm isn't doing anything wrong, it might
be some kind of server thing.

I don't really see how the logic for one step is much different
than the logic for 2 steps.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 20 Mar 2001 03:48:40 +0100

> is supposed to be, xwininfo prints the information for the window.

Hm.  The test uses xterms, so pressing ctrl-button1 on the place
where the window is supposed to be may bring up an xterm menu.
Does fvwm ever get a MapNotify event on the window?  I.e. is the
frame window ever mapped?

> be some kind of server thing.

So, what happens if you add usleeps and XSync's everywhere in this
code:

      if (!is_mapped)
      {
	is_mapped = True;
      }

E.g.:

      if (steps == 1) {
        XSync(dpy, 0);
        usleep(100000);
      }
      if (!is_mapped)
      {
        if (steps == 1) {
          XSync(dpy, 0);
          usleep(500000);
        }
	is_mapped = True;
      }
      if (steps == 1) {
        XSync(dpy, 0);
      }

Does this or a subset of this help?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 20 Mar 2001 19:38:20 -0500

> where the window is supposed to be may bring up an xterm menu.

It doesn't.

> frame window ever mapped?

As best I can tell, yes.  Since I can't use Xnest, I'm using
Exceed telnet to run gdb.  Since I only have one pointer, moving
the pointer into the telnet window causes map notifies for an override
redirect window, but I also see it get a MapNotify event and do:

  XMapSubwindows(dpy, Tmp_win->frame);
  XMapSubwindows(dpy, Tmp_win->decor_w);

When I click on the arrow.

> Does this or a subset of this help?

No.

I used FvwmCommand to issue a Recapture and the window appeared.

I read about XMapWindow and XMapSubWindow and it seemed like using
both was overkill so I took out the XMapWindow.  It didn't fix
the problem, but the other slide out panels worked fine.
Maybe the XMapWindow should be removed.

I did a RecaptureWindow from FvwmCommand and clicked in the center of
the area where the window should be and I noticed something funny.
First the xterm window appeared and then the Fvwm frame appeared.
The odd thing is, my xterm backgrounds are black, and I noticed a
yellow border around the window.  I remembered seeing that with twm
so I looked in my x resources and sure enough, I have:

XTerm*BorderColor:	yellow
XTerm*borderColor:	yellow

Is it correct for Fvwm to be covering up the xterm border?

My XMapWindow man page says:

     If the window becomes viewable and no earlier contents for
     it are remembered, the X server tiles the window with its
     background.

(This sounds like whats happening.)

     If the window's background is undefined, the
     existing screen contents are not altered, and the X server
     generates zero or more Expose events.  If backing-store was
     maintained while the window was unmapped, no Expose events
     are generated.  If backing-store will now be maintained, a
     full-window exposure is always generated.  Otherwise, only
     visible regions may be reported.  Similar tiling and expo-
     sure take place for any newly viewable inferiors.

     If the window is an InputOutput window, XMapWindow generates
     Expose events on each InputOutput window that it causes to
     be displayed.  If the client maps and paints the window and
     if the client begins processing events, the window is
     painted twice.  To avoid this, first ask for Expose events
     and then map the window, so the client processes input
     events as usual.  The event list will include Expose for
     each window that has appeared on the screen. The client's
     normal response to an Expose event should be to repaint the
     window.  This method usually leads to simpler programs and
     to proper interaction with window managers.

I don't understand how to ask for expose events before we map
the window.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 21 Mar 2001 11:53:42 +0100

> I used FvwmCommand to issue a Recapture and the window appeared.

So fvwm has properly swallowed and mapped the window, but did not
get any Expose events or the server ignored any drawing requests.
There are several ways to try to force a redraw:

 - Move another window across it (with "Style * backingstoreoff").

 - Give it Focus via FvwmCommand:

     next (bd) Focus

 - Refresh the window with the RefreshWindow command.

> Maybe the XMapWindow should be removed.

Hm.  The man page does not state that XMapSubwindows() will map
the parent window too:

       The XMapSubwindows function maps all subwindows for a
       specified window in top-to-bottom stacking order.  The X
       server generates Expose events on each newly displayed
       window.  This may be much more efficient than mapping many
       windows one at a time because the server needs to perform
       much of the work only once, for all of the windows, rather
       than for each window.

> Is it correct for Fvwm to be covering up the xterm border?

When fvwm captures a window it sets the window's border width to
zero because it provides its own border.  This is pretty standard
among window managers.

> I don't understand how to ask for expose events before we map

You can't.  In my eyes that's one major shortcomings of X.  You
can't reliably draw into unviewable windows either.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 22 Mar 2001 09:37:19 -0500

The FvwmButtons test with 1 step works fine at work.
Its either the Exceed X server or my slow connection that causes
the problem.  Since this doesn't appear to be an fvwm problem, I think
we can consider the issue closed.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 22 Mar 2001 16:09:10 +0100

> we can consider the issue closed.

Maybe.  I wouldn't discuss this problem in such detail if there
had not been other reports that redraws of certain window areas
were missing under obscure circumstances.  I'd at least like to
know the cause of the problem.  If all else fails, we could still
send a synthetic Expose event to the applications (given that it
solves the problem).

Bye

Dominik ^_^  ^_^