Subject: to do for 2.4

From: Dominik Vogt <[email-masked]>
Date: Thu, 17 Jun 1999 00:11:52 +0200

Well, I really had hoped someone else would volunteer for pushing
the project towards 2.4. Seems that I have to do it again then
(no hard feelings, I'm just under stress and perhaps there's a tiny
bit of disappointment too).

Here's a much more complete list of open issues (without the future
enhancements, I'll move them to a separate thread):

To do (must):

 1) Document the GNOME stuff (man page still missing).
 2) Add screen shots to web page.
 3) Add link to fvwm cats page to web page.
 4) Add link to Mikhael' wm-icons page.
 5) Update the links on our home page.
 6) Remove several configure options.
 7) Create an I18N fvwm package (from 2.2 or so).
 8) Add an explanation about the various packages and where to
    discuss them to the web page.
    (stable, unstable (alpha), snapshots, ftp source tree, CVS).
 9) Set up RPM packages.

To do (optional)

 10) Remove 'PopupAsRootMenu' menu style (?).
     [comments wanted]
 11) Add FvwmKb module?
     [comments wanted]
 12) Set up bzip2 tarballs.
 13) Use a 'busy' pointer during startup.

Fixes (high priority):

 14) Figure out what the problem with Amaya is.
     [reported on 3-Jun-1999 by Rob Urban <[email-masked]>]
 15) Get restart straight (sometimes an application vanishes over restarts)
 16) Try to fix the 'netscape stuck on page' problem.
     [reported on 17-May-1999 by <[email-masked]>]
 17) Fix the bug that causes icons to lose management (bug #352).
 18) Check if there are still growing windows as reported for 2.13.
     [bug #184 reported by Michael Hughes <[email-masked]>]
 19) Try to reproduce that KFM windows stay on top of normal fvwm windows.
     [reported by Andrew Morton <[email-masked]> on 16-May-1999]
 20) Check why no icon can be set for Eterm.
     [reported on 8-May-1999 by Amir Chossrow Akhavan <[email-masked]>]
 21) Fix the bug with eterm and transparent background (I think rxvt has
     the same problem.
 22) Investigate bug #290.
     [mail thread from April]
 23) Check if bug #312 is still there.
 24) Investigate bug #314.
 25) Investigate dying pager on desk-to-desk transfers (bug #358 et al.)
 26) Investigate bug #315.
 27) Check if bug #334 is still a problem.
 28) Investigate FvemEvent core dumps.

Fixes (optional):

 29) Fix the pager bugs I reported recently.
 30) Fix the broken size hints of FvwmWinList (in fvwm itself).
     [reported by Dan, verified by me (Dominik)]
 31) 'Maximize grow grow' works only on the current page.
     [reported by me (Dominik)]
 32) Several applications are reported to not resize well under fvwm
     (Datek's "Streamer", CodeWarrior).

Testing:

 33) Test the GNOME patches.
 34) Run the purify script again (and update it).
 35) Test the strokes patch.
 36) Test the new menu styles (ItemFormat!)
 
===

If anybody wants to help, please concentrate on one of the following items
for the first sweep:

1-5, 7-9, 12, 33, any of the high priority bugs.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Dan Espen <[email-masked]>
Date: Thu, 17 Jun 1999 14:32:51 -0400

> bit of disappointment too).

Sorry, I couldn't do it justice right now.  I'll try to help as I can.

>  3) Add link to fvwm cats page to web page.

The FAQ is currently linked to the cats page.  (The 2.3.x FAQ that is.)
Are you looking for more?

>  6) Remove several configure options.

Doesn't sound like a must.

>     (stable, unstable (alpha), snapshots, ftp source tree, CVS).

Must?

>      [reported by Dan, verified by me (Dominik)]

Change to must?

--
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: TG <[email-masked]>
Date: Thu, 17 Jun 1999 22:51:55 +0200

> Doesn't sound like a must.

I don't know which options would be removed, but I like all the "disable
options", because I don't need all those gradient, pixmap and other
"flashy" stuff. Compiling fvwm with them doesn't make sense for me. I
know this is just personal taste..

> Must?

I can set up an RPM package for i386.. if I can find out how to build
the specs of course one day.

Greetings,

Tung

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 18 Jun 1999 00:55:06 +0200

> Are you looking for more?

Of course! The must be a big, flashy, colourful link from the first page
of the web page! Or even better: make it the frontpage 8-)

> Doesn't sound like a must.

Ah, I'll do it anyway in the next days, 

> Must?

Not really. I wanted to emphasize that it's important. People keep
asking me about it.

> >      [reported by Dan, verified by me (Dominik)]

Why not. On the other hand we could simply fix it. I think we agreed that
the problem is that fvwm prints the message when an application requests
zero size increments. This isn't really illegal.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 18 Jun 1999 00:58:12 +0200

> know this is just personal taste..

Because it's hard to maintain. Disabling all options (at least the ones
I'm planning to remove) will save no more than 20k code and a few k
of dynamic memory. That's not worth the additional effort and pain.

> the specs of course one day.

I think Jason just needs the spec to set up a script to do it automatically.
If anybody can provide the spec we'd be grateful.

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 18 Jun 1999 01:36:04 +0200

>  13) Use a 'busy' pointer during startup.

I did a little experiment with this, and I don't know if it is worth
it. We can easily change the root cursor - or even all the fvwm-controlled
cursors, but many apps (even xterms) will still use their own cursors.
Changing these would be difficult, since we would have to reset them to 
their old (unknown) values after restart.

But if changing only the root cursor makes you happy, I'll commit the
5 lines necessary to do it.

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.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: Dominik Vogt <[email-masked]>
Date: Fri, 18 Jun 1999 02:07:05 +0200

> their old (unknown) values after restart.

??? We can simply grab the pointer with the desired cursor during startup.
You don't see application cursors while moving, using menus etc.

Bye

Dominik ^_^

---

From: Jason L Tibbitts III <[email-masked]>
Date: 17 Jun 1999 20:31:59 -0500

>>>>> "DE" == Dan Espen <[email-masked]> writes:

DE> Sorry, I couldn't do it justice right now.  I'll try to help as I can.

Dom also mentioned me, but unfortunately I have to take more of a sysadmin
role here because my C is realy rusty.  If FVWM were written in Perl I'd
have no problem.  As it is, Majordomo must take the bulk of what free time
I have.

 - J<

---

From: Jason L Tibbitts III <[email-masked]>
Date: 17 Jun 1999 20:44:24 -0500

>>>>> "DV" == Dominik Vogt <[email-masked]> writes:

DV> I think Jason just needs the spec to set up a script to do it
DV> automatically. If anybody can provide the spec we'd be grateful.

I actually have the spec (well, as part of a src.rpm which was recently
uploaded).  Now I just need to find some time to set up a build on an
up-to-date Linux machine.

I actually have the machine; we took apart a small Beowulf cluster so I
have some PPro200s sitting around.  I have one set aside but haven't found
the time to start moving services over to it.

 - J<

---

From: Michael Han <[email-masked]>
Date: Thu, 17 Jun 1999 22:25:56 -0700

Previously...
>     [reported on 3-Jun-1999 by Rob Urban <[email-masked]>]

Nothing's really been heard on this after a few people (including me)
tried unsuccessfully to reproduce the problem. I was hoping to see a
version number and a reference to the motif library in use.

> 28) Investigate FvemEvent core dumps.

Do you mean the one that Thomas was reporting a few weeks back? I
noticed you'd been looking for the report... I'm including it at the
bottom of my message. I've been looking this one over and I can't make
heads or tails of his gdb output.

It appears to core in strcasecmp(), because the first arg is NULL. Now
I don't understand this, because it's being called by MatchToken() in
libs/Parse.c, which is supposed to verify that

if (ntok) 

before calling strcasecmp() with ntok as the first arg. What's even
stranger is this is called from config() in FvwmEvent.c, where the arg
that's being fed to MatchToken() is coming from the event_table. I
don't understand how in the world *any* event_table[i].name could
possibly be NULL, as long as "i" starts at 0 and increments as long as
it's less than MAX_MESSAGES+MAX_BUILTIN.

Just tried to duplicate the bug, and couldn't. I'm all out of ideas on
what this bug is all about. Anyone got any ideas? Seems to have
originated from a clean compilation of 2.2.2.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"If you lend me some money, it'll be my treat."

-- 
Forwarded message [with a lot snippage]

Date: Fri, 11 Jun 1999 19:27:29 -0400 (EDT)
From: "Thomas A. Gardiner" <[email-masked]>
Subject: FVWM: FvwmEvent Core Dumps
Message-ID: <[email-masked]>

[tom@d185fcdc5 tom]$ gdb /home/tom/fvwm2.2.2/libexec/fvwm/2.2.2/FvwmEvent 
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) core core
Core was generated by `/home/tom/fvwm2.2.2/libexec/fvwm/2.2.2//FvwmEvent
13 4 /tmp/fvwmrca28862 0 8'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  __strcasecmp (s1=0x0, s2=0x8050ae0 "focus_change_window")
    at ../sysdeps/generic/strcasecmp.c:37
../sysdeps/generic/strcasecmp.c:37: No such file or directory.
(gdb) where
#0  __strcasecmp (s1=0x0, s2=0x8050ae0 "focus_change_window")
    at ../sysdeps/generic/strcasecmp.c:37
#1  0x8049d1d in MatchToken (pstr=0x8050ab0 "focus_change_window",
tok=0x0)
    at Parse.c:202
#2  0x80492a7 in config () at FvwmEvent.c:460
#3  0x8048e7f in main (argc=6, argv=0xbffffbd4) at FvwmEvent.c:251
(gdb) 

This time however I've looked at the file FvwmEvent.c and can only find
one instance of strcasecmp and that is

#ifdef HAVE_RPLAY
    /*
     * Builtin rplay support is enabled when FvwmAudioPlayCmd ==
builtin-rplay.
     */
    if (strcasecmp(cmd_line, "builtin-rplay") == 0)
	if ((rplay_fd = rplay_open(host)) < 0)
	{
	    rplay_perror("rplay_open");
	    exit(1);
	}
#endif

So what gives???

Thanks Much in advance,

Tom
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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.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: Dominik Vogt <[email-masked]>
Date: Fri, 18 Jun 1999 13:04:06 -0600

On Thu, Jun 17, 1999 at 08:31:59PM -0500, [email-masked] wrote:
> role here because my C is realy rusty.

Don't put pressure on yourself. Nobody expects that you start hacking C code.
As it is you take lots of work off our backs. Work that most of us would hate.
We're in no particular hurry at the moment. 

> If FVWM were written in Perl I'd have no problem.

Was it ever considered to write modules as shell scripts 8-)

> As it is, Majordomo must take the bulk of what free time I have.

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.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: Dan Espen <[email-masked]>
Date: Fri, 18 Jun 1999 08:17:50 -0400

> 5 lines necessary to do it.

I see no problem with the cursor only changing on the root.  It always
seemed to me that the window manager "owns" the root,  so I think this
would convey the feedback I was  looking for.  (Ie. the window manager
is busy.)

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 18 Jun 1999 08:29:22 -0400

> the time to start moving services over to it.

if we put the spec into the CVS tree as fvwm2.spec.in you can put all
the versioning stuff as variables and when you do the configure you'll
get a fvwm2.spec that has all the current values set to build your rpms.
But your right the best starting point is probabbly using an already
built srpm.

Brad

-- 
--- 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.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: Matthias Clasen <[email-masked]>
Date: Fri, 18 Jun 1999 16:35:45 +0200

> You don't see application cursors while moving, using menus etc.

This would be ok during startup, what I tried to do was: changing to
"busy" at the beginning of Done() (old wm) and change back at the 
end of StartupStuff() (new wm) - it would be difficult do a grab for
that. But the amount of time taken up by Done() is probably neglegible
anyway, so doing the grab only at startup time would be a good solution.
And we even have the hooks for it in place: we could simply add it to
the (Un)BlackoutWindow() functions. 

Matthias

---

From: Jason L Tibbitts III <[email-masked]>
Date: 18 Jun 1999 09:57:38 -0500

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

BG> if we put the spec into the CVS tree as fvwm2.spec.in you can put all
BG> the versioning stuff as variables and when you do the configure you'll
BG> get a fvwm2.spec that has all the current values set to build your
BG> rpms.

Ooh.  Yes, that is definitely something we want to do.  I'll extract the
spec from the src.rpm I have; where in the tree should it go?

 - J<

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 18 Jun 1999 11:21:12 -0400

> spec from the src.rpm I have; where in the tree should it go?

It should go in /home/cvs/fvwm/fvwm/
i.e. the same dir as configure lib/ fvwm/ modules/ ...

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 18 Jun 1999 17:21:35 -0600

> the (Un)BlackoutWindow() functions. 

Hm, I like Dan's reasoning that the pointer on the root window is sufficient.
Let's simply try it out. If we don't like the result we can do the more
complex solution with grabbing. BTW, I'd prefer the 'shuttle' cursor for
startup (I did mention that I don't like clocks/watches, didn't I :) ).

Bye

Dominik ^_^

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 18 Jun 1999 11:23:23 -0400

> the (Un)BlackoutWindow() functions. 

Just a thought here but what about folks that set the root cursor in
their init Function, won't the busy cursor blow it away or are you
somehow caching the cursor.  My init function does something like start
4 modules then run xsetroot to set the cursor.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 18 Jun 1999 11:06:42 -0500

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

BG> It should go in /home/cvs/fvwm/fvwm/ i.e. the same dir as configure
BG> lib/ fvwm/ modules/ ...

Hmmm.  What about the debian package spec?  One for Stampede?  Solaris?
Would a 'packaging' subdirectory be a better idea?

 - J<

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 18 Jun 1999 12:14:06 -0400

> Would a 'packaging' subdirectory be a better idea?

well I know that rpm likes to have its spec file at the top level. I
know you can force it with a switch to look somewhere else in the source
tree, but I've had trouble with that in the past. as for the others I'm
not really sure I haven't tried the other Linux packiging systems yet,
and I gave up on Solaris packages a long time ago.

Brad

---

From: Steve Robbins <[email-masked]>
Date: Fri, 18 Jun 1999 12:22:37 -0400 (EDT)

> Was it ever considered to write modules as shell scripts 8-)

Absolutely!  look for FvwmCommand.sh ;-) 

--
Steve Robbins                              <[email-masked]>

It's the end of the world as we know it, and I feel fine.

---

From: Dan Espen <[email-masked]>
Date: Fri, 18 Jun 1999 13:02:21 -0400

> startup (I did mention that I don't like clocks/watches, didn't I :) ).

I have my preferences too, some of them, even I recognize as weird, but
the idea was to enhance user  feedback.

I think the clock or watch is the "right" default.

I assume there is a way to capture the current cursor, set by the user
and restore it.

My root cursor preference is xaniroc.