Subject: FvwmAnimate probs.

From: [email-masked] (Paul D. Smith)
Date: 10 Nov 1998 16:28:00 -0500

I upgraded to the latest source, and noticed these problems:

 1) The new colors seem like they'd be cool, but something's wrong.  I
    used to get an animated frame that was mostly white (it seemed to
    me) and easy to see.  With the new FvwmAnimate when I keep the
    default "Black^White", the frame is a medium blue which is hard to
    see.

    In fact, I can't seem to find any of the colors that really show up
    well against my background :(

 2) In the customize Form, I left the color field blank and FvwmAnimate
    dumped core :).  In FvwmAnimate.c:903, GetArgument() is returning a
    NULL ptr but is later passed to strncasecmp() without checking...

-- 
-------------------------------------------------------------------------------
 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.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: Dan Espen <[email-masked]>
Date: Tue, 10 Nov 1998 17:47:06 -0500

>     well against my background :(

The default Black^White hasn't changed.  Its the same XOR pattern
fvwm uses for resize and move frames.

Since the animation frame color XORs into the background, and on non-true
color displays, you are XORing a color cell number into another color
cell number, you have to expect less than ideal results.

Are you using true color, 8 bit, or 16 bit?

On my 8 bit display, using solid  backgrounds, I usually saw something
with the default, but some colors  gave me nothing, where other colors
produced nice effects.  I never got the color I called for.

>     NULL ptr but is later passed to strncasecmp() without checking...

Not good, I'll get to  it.  It would be neat  if FvwmForm had required
fields.

> --
>  Paul D. Smith <[email-masked]>         Network Management Developmen

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
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: [email-masked] (Paul D. Smith)
Date: 10 Nov 1998 20:08:08 -0500

%% Dan Espen <[email-masked]> writes:

  de> The default Black^White hasn't changed.  Its the same XOR pattern
  de> fvwm uses for resize and move frames.

Hm.  It's not working for me :(.  It's definitely not the same as for
resize and move.

  de> Since the animation frame color XORs into the background, and on
  de> non-true color displays, you are XORing a color cell number into
  de> another color cell number, you have to expect less than ideal
  de> results.

Yah, I was just going to try them until one jumped out at me; none did
then FvwmAnimate dumped core :)

Note I didn't have any lines about color in my (old) .FvwmAnimate file;
I wonder if that matters?

  de> Are you using true color, 8 bit, or 16 bit?

I'm running on a SPARC SunOS system with an X11 (not Openwindows)
server; it's 8-bit PsuedoColor, as best as I can tell.

  de> On my 8 bit display, using solid backgrounds, I usually saw
  de> something with the default, but some colors gave me nothing, where
  de> other colors produced nice effects.  I never got the color I
  de> called for.

The "old" default, and the other wire frames, are fine for me.  I'll see
if I can't get them back and play a little more.

---

From: Dan Espen <[email-masked]>
Date: Tue, 10 Nov 1998 22:38:41 -0500

>     NULL ptr but is later passed to strncasecmp() without checking...

I fixed this in FvwmAnimate,  then realised  that  I copied the  logic
from FvwmEvent.  I then fixed this  in FvwmEvent, and during trying to
test FvwmEvent  using  FvwmTalk, I realized I  had  previously fixed a
command truncation  problem  in  FvwmAnimate   that I also    got from
FvwmEvent.  Which I then also fixed in FvwmEvent.

Is everybody following this?

What  I am trying to say  is, I've just  checked  in FvwmAnimate.c and
FvwmEvent.c and their changelogs.

> -- 
>  Paul D. Smith <[email-masked]>

---

From: Tim Phipps <[email-masked]>
Date: Wed, 11 Nov 1998 18:09:16 +0000

Just noticed that you couldn't get zoom3d effects apart from when the
effect is random.  The problem is in a strncasecmp which matches zoom
with zoom3d.  Could be fixed by reordering the effects array but here's
a patch that changed the name of zoom3d to 3dzoom.

Cheers,
Tim.

Index: FvwmAnimate.1
===================================================================
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmAnimate/FvwmAnimate.1,v
retrieving revision 1.2
diff -u -r1.2 FvwmAnimate.1
--- FvwmAnimate.1	1998/11/07 19:29:09	1.2
+++ FvwmAnimate.1	1998/11/11 18:08:10
@@ -97,7 +97,7 @@
 \fILines\fP,
 \fIFlip\fP,
 \fITurn\fP,
-\fIZoom3D\fP,
+\fI3DZoom\fP,
 \fITwist\fP
 \fIRandom\fP,
 and
Index: FvwmAnimate.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmAnimate/FvwmAnimate.c,v
retrieving revision 1.7
diff -u -r1.7 FvwmAnimate.c
--- FvwmAnimate.c	1998/11/11 03:27:49	1.7
+++ FvwmAnimate.c	1998/11/11 18:08:29
@@ -143,7 +143,7 @@
   {"Random",0,AnimateResizeRandom},
   {"Flip",0,AnimateResizeFlip},
   {"Frame","Zoom",AnimateResizeZoom},
-  {"Frame3D","Zoom3D",AnimateResizeZoom3D},
+  {"3DFrame","3DZoom",AnimateResizeZoom3D},
   {"Lines",0,AnimateResizeLines},
   {"Turn",0,AnimateResizeTurn},
   {"Twist",0,AnimateResizeTwist}
@@ -1120,7 +1120,7 @@
   CMD10("AddToMenu MenuEffects%s \"&1. Effect Random\" %sEffect Random");
   CMD10("AddToMenu MenuEffects%s \"&2. Effect Flip\" %sEffect Flip");
   CMD10("AddToMenu MenuEffects%s \"&3. Effect Frame\" %sEffect Frame");
-  CMD10("AddToMenu MenuEffects%s \"&4. Effect Frame3D\" %sEffect Frame3D");
+  CMD10("AddToMenu MenuEffects%s \"&4. Effect 3DZoom\" %sEffect 3DZoom");
   CMD10("AddToMenu MenuEffects%s \"&5. Effect Lines\" %sEffect Lines");
   CMD10("AddToMenu MenuEffects%s \"&6. Effect Turn\" %sEffect Turn");
   CMD10("AddToMenu MenuEffects%s \"&7. Effect Twist\" %sEffect Twist");
@@ -1215,7 +1215,7 @@
   CMD1V("*Form%sChoice RANDOM RANDOM %s \"Random\"",effects[1].button);
   CMD1V("*Form%sChoice FLIP FLIP %s \"Flip\"",effects[2].button);
   CMD1V("*Form%sChoice FRAME FRAME %s \"Frame\"",effects[3].button);
-  CMD1V("*Form%sChoice FRAME3D FRAME3D %s \"Frame3d\"",effects[4].button);
+  CMD1V("*Form%sChoice FRAME3D FRAME3D %s \"3dZoom\"",effects[4].button);
   CMD1V("*Form%sChoice LINES LINES %s \"Lines\"",effects[5].button);
   CMD1V("*Form%sChoice TURN TURN %s \"Turn\"",effects[6].button);
   CMD1V("*Form%sChoice TWIST TWIST %s \"Twist\"",effects[7].button);
@@ -1252,7 +1252,7 @@
   CMD11("*Form%sCommand      *%sEffect $(RANDOM?Random)\
 $(FLIP?Flip)\
 $(FRAME?Frame)\
-$(FRAME3D?Frame3d)\
+$(FRAME3D?3dZoom)\
 $(LINES?Lines)\
 $(TURN?Turn)\
 $(TWIST?Twist)");
@@ -1265,7 +1265,7 @@
   CMD11("*Form%sCommand      *%sEffect $(RANDOM?Random)\
 $(FLIP?Flip)\
 $(FRAME?Frame)\
-$(FRAME3D?Frame3d)\
+$(FRAME3D?3dZoom)\
 $(LINES?Lines)\
 $(TURN?Turn)\
 $(TWIST?Twist)");

---

From: Dan Espen <[email-masked]>
Date: Wed, 11 Nov 1998 14:45:37 -0500

> a patch that changed the name of zoom3d to 3dzoom.

You know, I  thought I noticed something  like that but it just didn't
sink in.  Thanks for the patch, but I decided I liked the names as is,
and I didn't like the strncasecmp approach this thing was using.

Except for the one case it needs it, I changed to strcasecmp and fixed
the problem.  The changes are committed.