Subject: WindowShading & "Eterm support"

From: Tomas Ogren <[email-masked]>
Date: Sat, 27 Feb 1999 21:39:00 +0100

If a window is shaded and moved, the window will be killed right now
since it gets a configure event with height == 0.

With this patch this won't happen, and I don't see the reason for
non-visible windows to know that you've been moved.
(Should go into the stable branch as well)

Animated shading coming to you within a few minutes...

/Tomas
-- 
Tomas Ögren, [email-masked], http://www.ing.umu.se/~stric/
|- Student of Computer Science at the University of Umeå
`- Sysadmin at {ing,acc}.umu.se
Index: move.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/move.c,v
retrieving revision 1.28
diff -u -r1.28 move.c
--- move.c	1999/02/23 14:57:57	1.28
+++ move.c	1999/02/27 20:21:31
@@ -83,7 +83,7 @@
 		   pointerX,pointerY);
     }
 #ifndef NO_ETERM_SUPPORT
-    if (tmp_win)
+    if (tmp_win && !(tmp_win->buttons & WSHADE))
     { /* send configure notify event for Eterm */
       XEvent client_event;
       client_event.type = ConfigureNotify;
@@ -669,7 +669,7 @@
 
 	}
 #ifndef NO_ETERM_SUPPORT
-      if (opaque_move)
+      if (opaque_move && !(tmp_win->buttons & WSHADE))
         { /* send configure notify event for Eterm */
           XEvent client_event;
           client_event.type = ConfigureNotify;

---

From: Jason L Tibbitts III <[email-masked]>
Date: 27 Feb 1999 15:20:43 -0600

Any nominations to give Tomas commit access?  Both patches look clean
although there are no ChangeLog entries.

BTW, should 'NO_ETERM_SUPPORT' be a runtime variable
(AnimatedMovesSendEvents or something)?  What's the tradeoff here?  Even
more round trips if you're doing Opaque or Animated moves?  I suppose that
if you're doing those you already don't care about bandwidth but it's
possible that you can handle an opaque move while your machine just falls
over with Eterm re-transparentizing itself every frame.

 - J<
--
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: Tomas Ogren <[email-masked]>
Date: Sat, 27 Feb 1999 23:22:33 +0100

> although there are no ChangeLog entries.

Some ChangeLog stuff:

1999-02-27  Tomas Ogren  <[email-masked]>

* move.c (AnimatedMoveAnyWindow, moveLoop): Added a check for shaded
windows, since sending configure events with a 0 pix high window is
disliked by X.

1999-02-27  Tomas Ogren  <[email-masked]>

* builtins.c (WindowShade): Enhanced WindowShade() to do animation, with
the number of steps configured by the command 'WindowShadeAnimate
<steps>'
* builtins.c: New function 'setShadeAnim()', called by the Fvwm command
'WindowShadeAnimate', sets the animation steps used in WindowShade().
* parse.h: Added F_SHADE_ANIMATE
* misc.h: Function prototype for setShadeAnim().
* functions.c: Added Fvwm command 'WindowShadeAnimate <steps>'

> over with Eterm re-transparentizing itself every frame.

I have butt-slow machines (~ 486/25) and it's no problem what-so-ever
over here.. so unless someone uses transparent Eterms and full opaque
movement on a 8086 I don't see much of a problem with it.. 8)

Btw, I attached a new diff since setShadeAnim didn't work if there were
no args at all (segfault, stupid me), also this is without the other
patch included.

/Tomas

---

From: Dan Espen <[email-masked]>
Date: Sat, 27 Feb 1999 17:27:05 -0500

----------
> although there are no ChangeLog entries.

Looking thru Tomas's contributions since 07/97 (mail archive)...sure.

--
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: Bob Woodside <[email-masked]>
Date: Sat, 27 Feb 1999 17:52:37 -0500 (EST)

> although there are no ChangeLog entries.

	I'll vote yea.

	I wish I'd pushed for including animated windowshade in 2.2.
My idea of putting it into a module ran into a few problems that I
never had time to try to resolve (if they can be resolved). But I miss
the feature; I used the 2.0.46 version of the patch for a long time,
and never had any problems with it.

> (AnimatedMovesSendEvents or something)?

	I think a runtime variable would be best. But, then, I'll vote
for runtime configuration of most anything (where feasible) over static
build-time configuration.

- Bob

---

From: [email-masked] (Paul D. Smith)
Date: 27 Feb 1999 20:48:28 -0500

Can someone explain, for those of us who despise eterm :), what the
switch is for?

-- 
-------------------------------------------------------------------------------
 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: Jason L Tibbitts III <[email-masked]>
Date: 27 Feb 1999 20:54:24 -0600

>>>>> "PDS" == Paul D Smith <[email-masked]> writes:

PDS> Can someone explain, for those of us who despise eterm :), what the
PDS> switch is for?

>From reading the source, it sends move events to the client as the window is
moved either by an animated or opaque move.  In both of these the window is
moving but previously fvwm didn't tell the client about it.  Thus the client
couldn't take notice of the fact that the window was changing position
until after the whole thing was done.

This only matters if the client cares where its window is at all times.
One such client is Eterm, which has extra knowledge of what's in the root
window and displays a darkened version of it as its window backgrounds.  It
makes for a cool effect if you prefer flash to readability.  With this
switch on it makes for a cooler (albeit mega-cpu-sucking) effect because
you can see things sliding over the root window.  Without it, it looks a
bit odd.

 - J<

---

From: Steve Robbins <[email-masked]>
Date: Sun, 28 Feb 1999 07:33:15 -0500 (EST)

On 27 Feb 1999, Jason L Tibbitts III wrote:

> moved either by an animated or opaque move.

If that is the case, then oughtn't the switch be called something more
descriptive than "NO_ETERM_SUPPORT"?

--
Steve Robbins                              <[email-masked]>

I was looking back to see
if you were looking back at me
to see me looking back at you.

---

From: Bob Woodside <[email-masked]>
Date: Sun, 28 Feb 1999 09:30:18 -0500

> descriptive than "NO_ETERM_SUPPORT"?

	I think that's what Jason originally suggested....

jlt>>  BTW, should 'NO_ETERM_SUPPORT' be a runtime variable
jlt>>  (AnimatedMovesSendEvents or something)?

- Bob