Subject: Re: FVWM: xterm VT Fonts resize action

From: "Randall S. Winchester" <[email-masked]>
Date: Wed, 22 Jan 1997 10:31:31 -0500 (EST)

Well I had not noticed this before, but playing around a bit, it looks like
the window is getting a resize sent to it which should not be happening as
an 80x24 window with one font is still an 80x24 window with another font.
The problem is also only seen when the font size increases.

If you do an ls -l in a window to fill up the screen then manualy make the
window thinner, then manualy put it back you will see similar behaviour.

If however you are in emacs or vi which understands the resize signal, every
thing gets restored after reexpanding.

I hope this provides a further hint. 

Randall

On Wed, 22 Jan 1997, Charles Hines wrote:

: >>>>> "Joey" == Joey Hess <[email-masked]> writes:
: 
: >> The "Unreadable" ( which is VERY SMALL ) behaves the same on dtwm but
: >> fvwm, although returning to the default size and Font, is blank over the
: >> "resized" width.
: >>
: >> ____________________     ______      ____________________
: >> |abcdef ghijk lmn  |     |:::: |     |abc                |
: >> |abcdef ghijk lmn  |     |:::: |     |abc                |
: >> |abcdef ghijk lmn  |     |:::: |     |abc                |
: >> |abcdef ghijk lmn  |  => -------  => |abc                |
: >> |abcdef ghijk lmn  |                 |abc                |
: >> |abcdef ghijk lmn  |                 |abc                |
: >> |abcdef ghijk lmn  |                 |abc                |
: >> |                  |                 |                   |
: >> --------------------                 ---------------------
: 
: Joey> I can verify that this is a bug caused by running fvwm as the window
: Joey> manager. I just ran X without a window manager, and my xterm did not
: Joey> exhibit this bug. Xterms managed by fvwm do show this bug.
: 
: Joey> I can't imagine why fvwm would be causing this behavior, though..
: 
: Joey> I'm running fvwm 2.0.43 on a linux system.
: 
: Yeah, this is a problem that I've known about for a while and it
: really bugs me, but I haven't been able to figure it out yet.  Note
: that it's new to 2.x -> 1.24r doesn't exhibit this behavior, but in
: comparing what is happening in the event handlers between the two
: versions I don't see any differences that would account for this.
: 
: I'm still looking into it though, and would really like to get it
: figured out before 2.1.0.  If anyone has any insights into it, please
: let me know.
: 
: Chuck
: --
: Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
: To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
: message to [email-masked].
: To report problems, send mail to [email-masked].
: 

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: "Charles Hines" <[email-masked]>
Date: Mon, 27 Jan 1997 13:09:06 -0500

Howdy all.

Remember that bug that was being discussed last week about the XTerm
changing fonts problem (loosing some of the screen when it resizes)?
Figured it out finially, I think.  Give the following patch a try, if
you'd like:

----------------------------------------------------------------------
--- ../../fvwm-2.0.45/fvwm/events.c     Wed Jan 22 08:37:39 1997
+++ ./events.c  Mon Jan 27 11:53:38 1997
@@ -513,6 +513,12 @@
        int new_width, new_height;

        GetWindowSizeHints (Tmp_win);
+        /*
+        ** ckh - not sure why this next stuff was here, but fvwm 1.xx
+        ** didn't do this, and it seems to cause a bug when changing
+        ** fonts in XTerm
+        */
+#if 0
        new_width = Tmp_win->frame_width;
        new_height = Tmp_win->frame_height;
        ConstrainSize(Tmp_win, &new_width, &new_height);
@@ -520,7 +526,7 @@
           (new_height != Tmp_win->frame_height))
          SetupFrame(Tmp_win,Tmp_win->frame_x, Tmp_win->frame_y,
                     new_width,new_height,False);
-
+#endif /* 0 */
        BroadcastConfig(M_CONFIGURE_WINDOW,Tmp_win);
       }
       break;
@@ -1294,6 +1300,7 @@
    * requested client window width; the inner height is the same as the
    * requested client window height plus any title bar slop.
    */
+  ConstrainSize(Tmp_win, &width, &height);
   SetupFrame (Tmp_win, x, y, width, height,sendEvent);
   KeepOnTop();

----------------------------------------------------------------------

(There is a patch from Mark Crimmins in there too, that he posted
eariler today.)

Please let me (& the list) know how it works or if it breaks anything.

Chuck

---

From: [email-masked]
Date: Mon, 27 Jan 1997 14:59:59 -0500

Well, tkgoodstuff depended on the min_width and min_height hints
being respected when sent to the wm.  But actually this was a hack
to get around the problem which my patch fixes.

MC