Subject: Re: fvwm-2.1.5 under hpux

From: Dominik Vogt <[email-masked]>
Date: Thu, 14 Jan 1999 04:07:33 +0100

On Wed, Dec 16, 1998 at 06:53:48PM -0700, Matthew Lovell wrote:
> Also, an extremely minor bug which existed in 2.0.46 is still around:
> 
>   1. WindowShade your favorite application.  XEmacs is a particularly
>      nice one to try.
> 
>   2. Switch to a different desk or even a different page on the same
>      desk. 
> 
>   3. Using the pager, drag the 'shaded' application into your current
>      desk/page. 
> 
> The shaded window invariable displays more than just the title bar. 

No need to switch desks or pages to get this. A move on the current
page will do. Anyway, I have fixed it.

Bye

Dominik

--
Dominik Vogt, [email-masked]
Reply-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: Matthias Clasen <[email-masked]>
Date: Thu, 14 Jan 1999 11:44:02 +0100

> page will do. Anyway, I have fixed it.

Yesterday I found a different way to fool shading:

 1) Shade an xterm
 
 2) Select a different font using the menu bound to C-M3 (it is
    a bit difficult to pop it up, as there the window is only
    1 pixel high.
  
 3) The xterm will resize itself, screwing up the geometry.

Actually, I think this should be considered in conjunction with
the problem of font change in a maximized xterm: 

I'd say fvwm should ignore client-side size changes if the 
window is maximized or shaded. 

This won't fix the "maximized xterm" problem, but after thinking
a bit about it, I'd say that it is a shortcoming of the X protocol
or the ICCCM: xterm really thinks of its own size in terms of 
"cell size" 
(ie the (i,j) in 
  width = base_width + i * width_inc
  height = base_height + j * hight_inc
), 
not "pixel size", but there is no way to indicate
in a ConfigureRequest that the client wants the "cell size" to
remain unchanged. A hacky workaround would be to save the "cell size"
when maximizing/shading and recompute the size to restore from
the saved "cell size" and the current size hints. Since this
wouldn't be good for arbitrary clients, it should be per-window
settable.

Matthias

-- 
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.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: Tim Phipps <tim@.quadrics.com>
Date: Thu, 14 Jan 1999 14:14:05 +0000

> window is maximized or shaded.

I think fvwm should do its best but I don't think we should consider
this enough of a bug to fix before 2.2

The ICCCM is pretty clear that clients should not change their geometry
hints when mapped.  This would make it very difficult to do the (useful)
font changing thing in xterm so I think we should try to get fvwm and
xterm to play nicely together.  Maybe unmaximizing and unshading a
window when the hints change and before recomputing the geometry would
be enough.  Unshading is more likely to succeed, unmaximizing may
require guessing that the client has only  changed its resize increments
and is not trying to grow.

Cheers,
Tim.

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 14 Jan 1999 15:34:13 +0100

> hints when mapped.  This would make it very difficult to do the (useful)

I have never found this statement in ICCCM. To the contrary, I read 
(4.1.2, Client Properties):

   The window manager will examine the contents of these properties when 
   the window makes the transition from the Withdrawn state and will monitor 
   some properties for changes while the window is in the Iconic or Normal
   state. 

Why would the wm monitor some properties if the client wouldn't be allowed
to change them ?
 
> and is not trying to grow.

If you save the "cell size" when maximizing/shading, you can use
compute a new cell size based on the requested size in the ConfigureRequest
and the current size hints and compare it to the saved cell size.
If they are the same, one could guess that the client only changed its
resize increments and wants to keep its "cell size".

But I'm not sure that your proposal would work. The problem I see is
that clients might change the geometry first and the hints later. Then
your propsal to unmaximize on property change would come too late.
I haven't exactly studied how xterm does it. I think i noticed

PropertyChangeNotify WM_NORMAL_HINTS
ConfigureRequest
PropertyChangeNotify WM_NORMAL_HINTS
PropertyChangeNotify WM_NORMAL_HINTS

but I didn't try to find out why there are three property changes.

---

From: Tim Phipps <[email-masked]>
Date: Thu, 14 Jan 1999 15:24:09 +0000

> (4.1.2, Client Properties):

OOOOPs, you're right, wonder where I got that idea from?

> but I didn't try to find out why there are three property changes.

Looks like it might be difficult.

Cheers,
Tim.

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 15 Jan 1999 02:11:21 +0100

> Looks like it might be difficult.
I have checked twm and afterstep, and they both show troublesome
behaviour (ie maximizing and font change don't commute). Perhaps
it is not worth doing anything about it.

---

From: Dan Espen <[email-masked]>
Date: Fri, 15 Jan 1999 09:20:59 -0500

> it is not worth doing anything about it.

Strangely enough, I have always EXPECTED fvwm to get confused by
doing this.  Perhaps because it is not apparent that a window is
in a maximised state,  I don't really expect fvwm to track it.
I know it attempts to, but when it looses track, for example after
restart, it seems like no big deal.

So I agree, its barely worth doing anything about it.

--
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.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].