Subject: FvwmPager

From: Dan Espen <[email-masked]>
Date: Wed, 28 Oct 1998 09:13:14 -0500

I've merged "animate_icons" and "menu_position".  I'm getting a problem
with FvwmPager, there is a band across the bottom like this:

With Sun's compiler, I get warnings during compile:

"FvwmPager.c", line 93: warning: initializer does not fit or is out of range: -1
"FvwmPager.c", line 94: warning: initializer does not fit or is out of range: -1
"FvwmPager.c", line 95: warning: initializer does not fit or is out of range: -1
"FvwmPager.c", line 96: warning: initializer does not fit or is out of range: -1

gcc doesn't complain about those lines.  I  get the same display error
with both compilers.

Purify finds one "array bounds read" problem:

 list_icon_name [FvwmPager.c:796]
        {
          if(t->icon_name != NULL)
            free(t->icon_name);
 =>       CopyString(&t->icon_name,(char *)(&body[3]));
          LabelWindow(t);
          LabelIconWindow(t);
        }

They say "CopyString" reads one byte beyond the end of a static area.
The must be refering to "&body[3]".

I don't think any of this explains the display problem.

My Pager config is:

*FvwmPagerBack gray
*FvwmPagerFore black
*FvwmPagerFont 9x15bold
*FvwmPagerSmallFont 5x8bold
*FvwmPagerHilight lightblue
*FvwmPagerGeometry -1-1
*FvwmPagerLabel 0 Main
*FvwmPagerLabel 1 Alt
*FvwmPagerDeskColor 0 blue
*FvwmPagerDeskColor 1 green
*FvwmPagerMiniIcons

And I start the pager with:

FvwmPager 0 1

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 28 Oct 1998 09:50:48 -0500 (EST)

> with FvwmPager, there is a band across the bottom like this:

I'm getting the same problem also using gcc and Sun's compiler on solaris
2.6 and 2.5.1

start with FvwmPager 0 0

DeskTopSize 2x4
*FvwmPagerHilight       orchid  
*FvwmPagerFore          black
*FvwmPagerBack          #515178
*FvwmPagerLabel 0       Home

*FvwmPagerBalloons            All
*FvwmPagerBalloonBack         Yellow
*FvwmPagerBalloonFore         Black
*FvwmPagerBalloonFont         lucidasanstypewriter-12
*FvwmPagerBalloonYOffset      +2
*FvwmPagerBalloonBorderWidth  1
*FvwmPagerBalloonBorderColor  Black

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

--
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: Dominik Vogt <[email-masked]>
Date: Wed, 28 Oct 1998 16:10:47 +0100

> The must be refering to "&body[3]".

That is probably one of my changes (I think I changed
the prvious code to the CopyString routine from the
library. Try using the old FvwmPager code (47d) and see
if the problems persist. If not I will have to look at
my changes again. You could help me a lot if you would
compare 47d and the menu_positions version of
FvwmPager.c and x_pager.c and see if you can find a bug
that I built in.

> I don't think any of this explains the display problem.

Neither do I.

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [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: Dominik Vogt <[email-masked]>
Date: Wed, 28 Oct 1998 18:34:44 +0100

> The must be refering to "&body[3]".

That's right. The problem is that the malloced area in
fvwm/modules.c is one unsigned long too short if the
strlen of the name is 0 mod 4.

modules.c lines 507-511:

  if(name == NULL)
    return;
  l=strlen(name)/(sizeof(unsigned long))+HEADER_SIZE+4;
  body = (unsigned long *)safemalloc(l*sizeof(unsigned long));

The buggy line in #509 and should be:

  l=strlen(name)/(sizeof(unsigned long)+1)+HEADER_SIZE+4;
                                      ^^^^

Will you integrate that fix into the combined animate/
menu_position branch? I will not make further changes
to my branch before the merge is done.

BTW, I the changer I made to FvwmPager and think they
are not responsible for the display bug.

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Oct 1998 19:08:10 +0100

>   l=strlen(name)/(sizeof(unsigned long)+1)+HEADER_SIZE+4;

Ahem, that's rubbish. The +1 must be applied to strlen(name)
of course:

  l=(strlen(name)+1)/(sizeof(unsigned long))+HEADER_SIZE+4;
   ^^^          ^^^^^                     ^^

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Oct 1998 19:18:16 +0100

>   l=(strlen(name)+1)/(sizeof(unsigned long))+HEADER_SIZE+4;

That's even more rubbish, sorry (I'm too tired to think clearly).
The original line is indeed correct. Just forget that I ever
said anything (can we delete this from the mail archive? ;-) ).

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Oct 1998 19:35:33 +0100

Now a *real* bug in FvwmPager.c:

(all line numbers refer to the menu_position branch)

in line 914 free(body) is called although body might
not point to an allocated area (this can indeed happen,
e.g. when the pipe to fvwm is broken):

         if(count = ReadFvwmPacket(fd[1],header,&body) > 0)
         {
           process_message(header[1],body);
           free(body);
         }
    }

This should be:

-->      body = NULL;
         if(count = ReadFvwmPacket(fd[1],header,&body) > 0)
         {
           process_message(header[1],body);
-->        if (body)
-->          free(body);
         }
    }

Ciao

Dominik

---

From: Dan Espen <[email-masked]>
Date: Wed, 28 Oct 1998 14:21:27 -0500

> to my branch before the merge is done.

I'm not sure what you are asking for here.   Both branches merge fine.
That is, there are no conflicts that CVS can't resolve.

If you are finding bugs anywhere  in fvwm, there is  no reason why you
can't apply them to the menu_position branch and  we can retrieve them
by way of "update -j".

> are not responsible for the display bug.

Perhaps not, but I only see the problem with the new version.

Have you noticed that the blank area at the bottom of the pager is
about the same size as the text titles at the top of the pager?

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Oct 1998 20:35:37 +0100

>From a previous posting I got the impression that you changed
parts of the menu stuff I worked on too. It's great news if
it merges fine.

I will create a branch 'anim_menu' today to incorporate
both branches. This should probably become the main
branch soon.

> about the same size as the text titles at the top of the pager?

Sorry, I did not have a look at this bug. I run fvwm only at
home but have no email there, so everything I say at the
moment is based on looking into the code.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Wed, 28 Oct 1998 15:22:43 -0500

> both branches. This should probably become the main

If you know CVS better than I do, pay  no attention to me.  Otherwise,
you don't need an 'anim_menu' branch.

I made my animation changes in

~/src/fvwm_animate/fvwm

from this directory, I upload changes to the main CVS tree.
When I wanted to merge your changes and mine, I wasn't sure I could
do that in the same place so I created the directory

~/src/fvwm_merge/fvwm

In the the fvwm_merge directory, I did:

cvs -z3 -d :pserver:[email-masked]:/home/cvs/fvwm \
 checkout -P -r animate_icons fvwm

cvs -z3 -d :pserver:[email-masked]:/home/cvs/fvwm \
 checkout -j menu_position fvwm

This creates a source tree with all our changes combined.  You can use
this area to do your testing from.

We wouldn't want to merge these into the main branch until we are sure
all these changes are OK and we want to create a release.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Oct 1998 21:40:27 +0100

> you don't need an 'anim_menu' branch.

No, CVS is quite new for me. But -- too late, the branch
is already there. Anyway I see no reason why we should
patch two concurrent branches when we can put everything
in a single one (some day the *will* be conflicts).

Anyway, try as I might, I CAN'T GET YOUR FvwmAnimate
directory into the new branch or a diff of it! Drats! This
MUST be possible somehow. What I did is:

I created the new branch from scratch, checked it out,
cd'ed into it's directory and merged the two branches
with:

cvs update -j menu_position
cvs update -j animate_icons

Why doesn't this work? It is definitely supposed to,
or am I missing something?

> this area to do your testing from.

I want a common branch so *everyone* can test this,
not just you, me and some CVS experts.

> all these changes are OK and we want to create a release.

Agreed.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Wed, 28 Oct 1998 15:52:09 -0500

> in a single one (some day the *will* be conflicts).

I think the idea is, each developer works in his own branch.
Not that a developer can't have more than 1 branch going at a time.

> or am I missing something?

I think you need to use "checkout", not "update".

Possibly after checkout, update would be OK, but I know you start with
checkout.

> not just you, me and some CVS experts.

Its not that hard. The 2 commands I sent are all thats needed.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Oct 1998 22:11:33 +0100

> Not that a developer can't have more than 1 branch going at a time.

Certainly. But that is not what I am concerned about
(see below).

> I think you need to use "checkout", not "update".

That did the trick. Thanks.

> Its not that hard. The 2 commands I sent are all thats needed.

Ahh, we are talking about different things. I do not care
about two additional commands to create the merged
version, but if we want to make a new release someday soon
we should join the branches to make a common code base for
further development/patching. Neither you nor I are making
notable changes to our branches now, so the natural thing
is to merge them.

I see this as the first step to our release. My opinion
is that we should make the merged branch the new
2.0.47e early next week or even this week.

Bye

Dominik

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 28 Oct 1998 16:39:43 EST

> or am I missing something?

You should also pass the -d option (create new directories) to cvs
update.

 - Maciej

---

From: Dan Espen <[email-masked]>
Date: Wed, 28 Oct 1998 16:46:59 -0500

> 2.0.47e early next week or even this week.

We need the Pager bug fixed first.

I need to at least comment out the X_Freecolors.

Since the letter at the end of 2.0.47e was used  to denote beta's that
were only announced to the workers list, I  think we are talking about
2.0.48?  (The  workers list has full  access to all our  changes right
now.)

One of us needs  to update the Changelog.  I  purposely didn't do that
for  my changes,  since  I was pretty  sure if   we  both did it,  CVS
wouldn't be able to sort out how to merge  them.  I'd like anyone that
has experience with this to give  some advice.  My  plan was to create
one more branch for release staging.  In it I  saw the changelog being
updated, and some of the maintainer info being made more current.

Anyone happen to notice:

modules/OLDFvwmWinList

that should be removed too.

The other thing I thought of for that branch  was adding a rule to the
IMakefile to create an actual package.  (Some kind of "tar" that would
not include the "CVS" directories.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Oct 1998 23:08:40 +0100

> We need the Pager bug fixed first.

I agree that this must be fixed fast, but that should not
prevent us from making 2.0.47e. This does not necessarily
mean we are closer to a new release. 47d was buggy too
as were 47a, 47b and 47c probably. Let us just agree on
*one* branch to fix and work on for the moment.

> 2.0.48?  (The  workers list has full  access to all our  changes right

Isn't the whole 2.0.x stuff supposed to be beta? At
least that is whats is said in the distribution. So I see
no real reason to do a beta test of the beta test.
The 2.0.47 would be more to tell people fvwm is still alive,
2.0.48 does little changes but inevitable bugfixes and the
path after this should be straight towards 2.1 (or 2.2).
 
> updated, and some of the maintainer info being made more current.

Sorry, I can't do that. I am lacking insight to do this,
but I have edited a few entries that I changed myself.
Hey Dan, you are more busy actually doing something than
I. Perhaps German had the right idea and you should be
the maintainer ;-)
 
> that should be removed too.

If there are no objections from anyone we should just do it.
Does anybody know the right way to remove a directory from
a branch?
 
> not include the "CVS" directories.

Perhaps that should wait until we have autoconf. That should
happen before 2.0.48, maybe even before 2.0.47.

Bye

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 28 Oct 1998 22:47:16 -0500

>> not include the "CVS" directories.

  dv> Perhaps that should wait until we have autoconf. That should
  dv> happen before 2.0.48, maybe even before 2.0.47.

Agreed.  Automake creates makefiles that provide extensive, builtin
targets for creating distributions.  It's quick, easy, and automatic.  I
wouldn't recommend spending another minute of anyone's time futzing with
Imakefiles.

-- 
-------------------------------------------------------------------------------
 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: Steve Robbins <[email-masked]>
Date: Wed, 28 Oct 1998 23:01:39 -0500 (EST)

> not include the "CVS" directories.

Yes, another two points in favour of putting in automake/autoconf right
now:

(4)  The makefiles have a "make dist" rule that creates a tar file for
distribution.  

EVEN BETTER: 

(5)  The generated makefiles include a "make distcheck" rule that checks
the tar bundle!  This rule does "make dist", then automatically unpacks
the tar file in a subdirectory, does "make" and "make install" to check
that all the necessary files are properly included.  

The quality is vastly improved by using "make distcheck" before releasing
the tar file.  Well worth the price of admission.

--
Steve Robbins                              <[email-masked]>

If mashed potatoes were security guards, they wouldn't get much done.

---

From: Dan Espen <[email-masked]>
Date: Wed, 28 Oct 1998 23:53:56 -0500

> Yes, another two points in favour of putting in automake/autoconf right

I don't need much convincing.

Have you contacted Jason for your update password?

Whether autoconf goes  in this release  or not, I  can't think  of any
reason why you shouldn't create a branch.  On the other hand, it won't
go in the release until the branch is created.

---

From: Dan Espen <[email-masked]>
Date: Thu, 29 Oct 1998 15:53:16 -0500

> Does anybody know the right way to remove a directory from

You rm the file, then commit.
Empty directories you just leave.
(You use a flag on checkout to drop empty directories.)

I've commited the changes to remove this directory to
the "animicons_menupos" branch.

Next on my hit list is the "usleep.c" file added in 2.0.47.
There is exactly the same function in the libs directory
under the name "sleep_a_little".

I'll wait a day or 2 for objections before proceeding.

---

From: Dan Espen <[email-masked]>
Date: Thu, 29 Oct 1998 16:08:37 -0500

> to my branch before the merge is done.

As you might be able to tell, I'm catching up on my mail.
This change is now committed.

---

From: Dan Espen <[email-masked]>
Date: Thu, 29 Oct 1998 20:58:51 -0500

>            process_message(header[1],body);

I'm sorry if we've covered this already, like I indicated, I'm going
thru my old mail.

It's true that the only condition that ReadFvwmPacket doesn't return a
"body"   is when   there is a   DeadPipe,  but  under  that condition,
module/Module.c  calls the DeadPipe() function   that  each module  is
required to provide.  The DeadPipe function must exit.

There is no need to make this change.

---

From: Magnus & Tina <[email-masked]>
Date: Fri, 30 Oct 1998 12:04:38 +0100 (GMT+0100)

Hi.

I have a problem I have been living with for a long time.
I have decided to tackle it now but need some help.

When I start or restart fvwm2 it hangs with a mouse pointer
like a circle. I then have to press any of the mouse buttons to let
fvwm2 continue.
It seems like it is hanging somewhere between start of X and parsing of
.fvwm2rc though I'm not sure.
It might also be something in my .fvwm2rc file. (Attached).

How do I debug this one?

/// Magnus Back

---

From: Magnus & Tina <[email-masked]>
Date: Fri, 30 Oct 1998 12:54:44 +0100 (GMT+0100)

I turned debuging on :-) and found that it is WindowShade
that hangs the startup. It doesn't matter if it is set to 1 or 2.
As long as I have Windowshade in the .fvwm2rc file, fvwm2 hangs.

/// Magnus

> It might also be something in my .fvwm2rc file. (Attached).

      .---.        .----------- Magnus Back
     /     \  __  /    ------   Nippon Ericsson K.K
    / /     \(  )/    -----     SY/NRJ/SV/F MBK
   //////   ' \/ `   ---        [email-masked] (work)
  //// / // :    : ---          [email-masked]             (home)
 // /   /  /`    '--            +81-45-475-0418 phone
//          //..\\              +81-45-475-0040 fax
       ====UU====UU====         http://www2.gol.com/users/magnus/
           '//||\\`            
             ''``
--
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: Magnus & Tina <[email-masked]>
Date: Fri, 30 Oct 1998 14:11:14 +0100 (GMT+0100)

A lot of functions in builtin.c uses the DeferExecution function.

 *      Procedure:
 *      DeferExecution - defer the execution of a function to the
 *          next button press if the context is C_ROOT
 *

At startup i guess the context is C_ROOT so this is always valid.
I don't know how to fix this.
Any hints?

/// Magnus

---

From: Magnus & Tina <[email-masked]>
Date: Fri, 30 Oct 1998 15:05:26 +0100 (GMT+0100)

Ooops!

Now I understand what it's supposed to do.
My placement of the WindowShade directive was totally wrong.
However, if windowshade is called in a context which isn't a window,
maybe it should shade or unshade all windows.
If you want to have windowshade in a menu that would be good.

Or maybe we should add WindowShade 3 which can mean this.
What do you think.

/// Magnus

---

From: Tim Phipps <[email-masked]>
Date: Fri, 30 Oct 1998 10:47:23 +0000

> Or maybe we should add WindowShade 3 which can mean this.

At the moment Fvwm doesn't have any operations that affect all windows,
you can't even do Next Next Something to move two windows around the
windowlist.  If you really want to do something to all windows I think
we should work on a more generic solution rather than just do it for one
command.  I think it would be nice to be able to apply the same
conditions that work with the Next & Prev commands so that e.g. you
could just affect all windows on the current desk, or all netscape
windows. It might be as simple as a command that calls a function with a
WindowID for every window e.g.

AddToFunc my_iconify_all "I" DoItToEverything my_iconify_one
AddToFunc my_iconify_one "I" WindowID $0 [CurrentDesk !Iconic] Iconify

This would require two things:
1) a DoItToEverything command
2) optional conditions for the WindowID command

I can't see a problem with 2), but 1) might be difficult.  Does anyone
have any idea if simply traversing the windowlist is dangerous if
arbitrary functions were to be called in the middle?  What I'm thinking
is that e.g. FlipFocus or Close might be called which would mess with
the windowlist and the DoItToEverything might fall off the list and
cause a coredump.  I don't understand the Fvwm list management stuff so
I don't know if this is a possibility or not.

Cheers,
Tim.

PS if this came to be, could we get rid of the daft numbers that Iconify
and WindowShade use?  I hate them, can never remember what to use, and
it would simplify those commands since they wouldn't need to do any
parsing.
--
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: Brad Giaccio <[email-masked]>
Date: Fri, 30 Oct 1998 07:55:40 -0500 (EST)

If you take a look at FvwmCommand (it is the extras area), there is an
example script called ex-grpmv.pl that when run gives you a list of all
the windows and lets you select which ones or all of them to execute
command on, in this case Move.  I'm not sure if this is the sort of thing
you had in mind but take a look.

Brad
P.S. There is a newer version you can grab at
http://www.concentric.net/~isogai/fvwm2/fvwm2.shtml

---

From: Tim Phipps <[email-masked]>
Date: Fri, 30 Oct 1998 13:08:46 +0000

> you had in mind but take a look.

Consider the proposal for DoItToAllWindows ditched.  Didn't like the
name anyway.
Cheers,
Tim.

---

From: Austin Donnelly <[email-masked]>
Date: Fri, 30 Oct 1998 13:25:32 +0000

> There is no need to make this change.

But it makes the code more robust, and this is a good thing when
someone else later changes how ReadFvwmPacket() behaves.

Austn

---

From: Dan Espen <[email-masked]>
Date: Fri, 30 Oct 1998 09:45:13 -0500

> someone else later changes how ReadFvwmPacket() behaves.

Yes, but, this was a  request to change FvwmPager.   I then looked  at
FvwmAnimate, I  would  have to change  it too.   I didn't  look at the
other modules, but my  guess is I would have  to change lots or all of
them.

Making sure ReadFvwmPacket always allocates a body so that the modules
can free it without checking seems like the way to go to me.  It keeps
the modules simpler too.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 30 Oct 1998 10:04:38 -0600

>>>>> "BG" == Brad Giaccio <[email-masked]> writes:

[FvwmCommand]
BG> There is a newer version you can grab at
BG> http://www.concentric.net/~isogai/fvwm2/fvwm2.shtml

There is some other stuff on this page that someone should look at getting
in to the mainline sources if appropriate.

 - J<

---

From: Magnus & Tina <[email-masked]>
Date: Sat, 31 Oct 1998 01:10:48 +0100 (GMT+0100)

To be frank I know more or less nothing about fvwm internals.
However I have regularly seen this Windowlist thing pop up as
a sort of job dispatcher. That might make sense.
However it always seems it isn't good enough and can't do
what people need.

This can "easily" be done by having a state oriented design.
(Which I like :-))
So windowlist then keeps track of the status of all windows.
When somebody wants a window to do something it sends the request to 
windowlist.

Windowlist must then have some way receiving jobs on individual basis,
group basis and global basis.

It should also be able to send back status information to other parts of the
code. It seems, by a quick look, that this is the only thing it does now.

Maybe this type of functionality is located elsewhere. (fvwm?).

But then why keep status in one place and keep track of jobs somewhere else?
That at least, won't work.

Does this make any sense or should I shut up now?

/// Magnus