Subject: Re: bug in 2.1.3 (can we still call it back?)

From: Dominik Vogt <[email-masked]>
Date: Tue, 1 Dec 1998 11:31:16 +0100

On Mon, Nov 30, 1998 at 03:36:56PM -0500, Paul Smith wrote:
> I'm willing to make a 2.1.4 now if people think it's a good idea.  How
> widespread is the bug that was fixed; e.g., will it affect everyone, or
> only people with a particular config?

I wouldn't make a 2.1.4 either if possible, but this bug will
certainly be found and will break certain setups badly.
It effectively prevents anything that needs ClickTime
from working.

But since the announcement hasn't been posted it's not
critical at all. We can just make 2.1.4 and announce this
one as the beta. Jason, can we agree on that you post
the announcement(s) (you'll have to edit it a little) as
soon as you put the tarball(s) on the ftp server?

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: [email-masked]
Date: Tue, 1 Dec 1998 09:35:15 -0500 (EST)

> It effectively prevents anything that needs ClickTime

Well, aside from the ClickTime problem, I found that PixmapPath is not
being parsed correctly in 2.1.3, making that version completely useless
for me:

[FVWM][executeModule]: <<ERROR>> No such module 'PixmapPath' in ModulePath '/usr
/lar3ry/libexec/fvwm/2.1.3:/usr/lar3ry/bin'
[FVWM][scanForPixmap]: <<WARNING>> Couldn't find pixmap mini.xterm.xpm
[FVWM][scanForPixmap]: <<WARNING>> Couldn't find pixmap mini-x2.xpm
[FVWM][scanForPixmap]: <<WARNING>> Couldn't find pixmap mini-x2.xpm
[FVWM][scanForPixmap]: <<WARNING>> Couldn't find pixmap mini.fvwm.xpm

[ ... ]

I filed a Jitterbug report on this (#40).

I'm going to go back to using 2.1.2 until the next release comes out (I
cannot access the CVS tree, unfortunately).

-- 
Larry Gensch					      [email-masked]

               "May I have ten thousand marbles, please?"

---

From: [email-masked]
Date: Tue, 1 Dec 1998 09:43:55 -0500 (EST)

Mea culpa!  I neglected to include the applicable part of my .fvwm2rc
file.  It appears that it's the parsing of the ModulePath that is
botched.

(On fvwm 2.1.2, the file works perfectly when I change the 2.1.3 to
2.1.2).

Side note:  is it required to put the location of the modules in my
.fvwm2rc file, or is the place where the modules were installed "known"
somehow by fvwm2.  It seems that I constantly have to update my
.fvwm2rc file to point to the new location every upgrade...

The applicable lines from my .fvwm2rc file:

ModulePath	/usr/lar3ry/libexec/fvwm/2.1.3:/usr/lar3ry/bin
PixmapPath	/usr/lar3ry/fvwm/icons
IconPath	/usr/lar3ry/fvwm/icons:/usr/include/X11/bitmaps

---

From: Jason L Tibbitts III <[email-masked]>
Date: 01 Dec 1998 09:34:04 -0600

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

DV> Jason, can we agree on that you post the announcement(s) (you'll have
DV> to edit it a little) as soon as you put the tarball(s) on the ftp
DV> server?

That's fine.  Unfortunately it seems we're in 'just one more important bug'
mode, which is good because there aren't fifty more important bugs, but
which is bad because it can go on forever...

 - J<

---

From: [email-masked] (Paul D. Smith)
Date: 01 Dec 1998 10:39:22 -0500

%% [email-masked] writes:

  lg> Side note:  is it required to put the location of the modules in my
  lg> .fvwm2rc file, or is the place where the modules were installed "known"
  lg> somehow by fvwm2.  It seems that I constantly have to update my
  lg> .fvwm2rc file to point to the new location every upgrade...

If you just want the general module directory, you can leave ModulePath
unset and fvwm2 will know where to look for it.

Unfortunately, if you want to modify the path (as you are, adding
/usr/lar3ry/bin) there is no way to do so without explicitly writing the
default module path as you've done.

I brought this up as an issue back when we first started using
version-specific module directories (which I like, don't get me wrong :)
but so far we haven't done anything about it.

I'll try to find my original mail and report it to Jitterbug.

-- 
-------------------------------------------------------------------------------
 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: "Randall S. Winchester" <[email-masked]>
Date: Tue, 1 Dec 1998 10:51:04 -0500 (EST)

On 1 Dec 1998, Jason L Tibbitts III wrote:

: >>>>> "DV" == Dominik Vogt <[email-masked]> writes:
: 
: DV> Jason, can we agree on that you post the announcement(s) (you'll have
: DV> to edit it a little) as soon as you put the tarball(s) on the ftp
: DV> server?
: 
: That's fine.  Unfortunately it seems we're in 'just one more important bug'
: mode, which is good because there aren't fifty more important bugs, but
: which is bad because it can go on forever...
: 
:  - J<

Well then maybe we should hold back on the beta for a few more days and
tighten this up little more. Freeze all additions except explicit and
*specific* bug fixes, and give workes a change to compile and run across
their platforms. What we currently have does not seem like a public beta.

Randall

---

From: [email-masked]
Date: Tue, 1 Dec 1998 10:57:29 -0500 (EST)

> default module path as you've done.

The big problem is tkgoodstuff, which I have apparently inherited.  I
have no desire to synchronize version numbers with fvwm and/or tk, so
the best thing for me is to install in the standard GNU ${prefix}
directory.

But it IS a module, so I could either symlink it to the fvwm modules
directory (which will apparently change with each release of fvwm2), or
add the standard directory somewhere in the ModulePath.  Which is why I
had the setup that you see.

> but so far we haven't done anything about it.

I remember seeing this on the workers list, but since I don't have CVS
access for a number of reasons, it wasn't until the dot releases came
out that I actually saw it.

Here are some unasked for suggestions:  [smile]

1.  Have fvwm2 "remember" its hardcoded directory and tack it onto the
    end of any ModulePath specified.

2.  ModulePath is documented to understand environment variables (at
    least, it says so in the man page).  Why not have $FVWM_MODULE_DIR
    or something similar set by fvwm2 so that the user need only
    specify it via a variable?

> I'll try to find my original mail and report it to Jitterbug.

Good idea!  Nice to be able to keep track of it.

Thanks for the reply.

---

From: [email-masked] (Paul D. Smith)
Date: 01 Dec 1998 12:24:59 -0500

lg> Here are some unasked for suggestions:  [smile]

  lg> 1.  Have fvwm2 "remember" its hardcoded directory and tack it onto the
  lg>     end of any ModulePath specified.

  lg> 2.  ModulePath is documented to understand environment variables (at
  lg>     least, it says so in the man page).  Why not have $FVWM_MODULE_DIR
  lg>     or something similar set by fvwm2 so that the user need only
  lg>     specify it via a variable?

Both of these were suggested, along with my original which is kind of a
combination of them; a special symbol like "+" could be inserted into
the module path where you wanted the default path to appear:

  ModulePath +:/my/module/dir

However, I suggested that something like #2 would be best because I
actually use this value in other places in the .fvwm2rc file (for
example, I have a little script that builds a menu of all the modules in
the module directory, and it needs to know the path).  It's too bad the
fvwm config file language doesn't have generic "variables" that could be
set like this; I guess you'd have to use FvwmCpp or FvwmM4.

Anyway, for lack of real concensus or drive to code it, it hasn't been
done yet :)

---

From: Dan Espen <[email-masked]>
Date: Tue, 01 Dec 1998 12:47:03 -0500

> Anyway, for lack of real concensus or drive to code it, it hasn't been

It seems to me all three alternatives are compatible.  We can implement
all 3.  So I would suggest we have concensus.  I thought we somewhat
purposely decided this was better done after the first official release.

> --
>  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: 01 Dec 1998 23:09:22 -0800

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

Bug #43.

  de> It seems to me all three alternatives are compatible.  We can
  de> implement all 3.  So I would suggest we have concensus.  I thought
  de> we somewhat purposely decided this was better done after the first
  de> official release.

Hmm.  I'm not sure I think that's a good idea.

We're introducing this new feature (installing modules in a
version-specific directory) so people who have a ModulePath already
(which is probably almost everyone since it was in the system.fvwm2rc)
are going to have to change their .fvwm2rc files for this.

I'd hate to have only partial support for this in the first release,
then tell them to change it _again_ for the next release.

MHO.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Dec 1998 11:50:42 +0100

> purposely decided this was better done after the first official release.

Well, obviously we were wrong. We should do something for this release.
If we can get existing config files running even better, so I think the
default path is searched always when all else fails.

I'm still without my Linux box, so can someone else take action?

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Wed, 02 Dec 1998 09:16:55 -0500

> I'm still without my Linux box, so can someone else take action?

I'm not following why you  would want to  change this kind of thing in
this release.  I thought we just wanted to fix bugs, not start in with
more enhancements.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Dec 1998 15:22:18 +0100

> this release.  I thought we just wanted to fix bugs, not start in with

It's like Paul said. We shouldn't force everyone to change his
config file to work again and then change is again shortly after.
I think the reason why this was forgotten is that we didn't
reach an agreement at first, then there were more pressing
things to do. There is one other thing I'm quite uncomfortable
with: We had no time to straighten up the MenuStyle syntax :(.

A small patch just to allow existing config files to work
(like appending the default dir at the end of the path)
would suffice and is not much work for now.

Bye

Dominik

---

From: [email-masked]
Date: Wed, 2 Dec 1998 09:29:20 -0500 (EST)

> this release.  I thought we just wanted to fix bugs, not start in with

Could it be conisdered a bug that each new release of fvwm2 requires
people to edit their configuration files?

---

From: Dan Espen <[email-masked]>
Date: Wed, 02 Dec 1998 09:37:38 -0500

> people to edit their configuration files?

OK, I  guess I'm just blind  to this because  I've  been using a shell
that exports a  module path environment variable  for a long time now,
and installing each new release in an area unique to the release, so I
don't see this as a new problem at all.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 02 Dec 1998 09:32:47 -0600

>>>>> "lg" == larry gensch <[email-masked]> writes:

lg> Could it be conisdered a bug that each new release of fvwm2 requires
lg> people to edit their configuration files?

If we're willing to say "it's still an alpha-quality hacking release" or
inform people that there will be config file changes between this release
and the next one, then no, that's not bugginess; it's progress.  If we're
trying to call it a beta test then we shouldn't be changing anything.

It's all about what the user is promised; a developer should not go making
promises that can't be kept ("this software is stable") and the user
shouldn't try to hold the developer to promises they didn't make ("your
alpha-quality software just isn't stable stable").

 - J<

---

From: [email-masked] (Paul D. Smith)
Date: 02 Dec 1998 11:18:05 -0500

jlt> If we're willing to say "it's still an alpha-quality hacking
  jlt> release" or inform people that there will be config file changes
  jlt> between this release and the next one, then no, that's not
  jlt> bugginess; it's progress.  If we're trying to call it a beta test
  jlt> then we shouldn't be changing anything.

I think we should use some numbers; when I say release here I'm talking
about 2.2.  I think 2.2 is supposed to be a Stable Release.

As such, I believe this problem to be significant enough, and
user-visible enough, that _something_ needs to be done to resolve it
before 2.2 goes out.

My opinion.

PS. Note that the environment variable thing is _really_easy_ to
    implement, just stick it into the environment in main() and you're
    done.  1 line, unless you want to test if the user set it first.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Dec 1998 17:33:28 +0100

> user-visible enough, that _something_ needs to be done to resolve it

Mine too. Even better if we'd do it with the beta. It is really only
a small patch. Appending the default path when ModulePath is called
isn't much of a deal either (just make sure the array is long enough).

Bye

Dominik

---

From: Lee Willis <[email-masked]>
Date: 02 Dec 1998 16:41:58 +0000

> isn't much of a deal either (just make sure the array is long enough).

As an 'outsider' it seems to me that you decided on doing a beta release
(Which I'd take to have bugs anyway ...) and then instead of releasing
it and immediately fixing the things you notice for 2.1.4 you're trying
to hold back the release of 2.1.3. This is (semi-)acceptable behaviour
with respect to a 'stable' release ie 2.2 but for beta releases I'd
think you're better off just releasing 2.1.3 let people use it for a
while. Meantime you're working on the bugs you know about and fixing
them for 2.1.4 and then you can work on the bugs people report from
2.1.3.

Just my 2p
Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"
--
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, 2 Dec 1998 17:47:36 +0100

> them for 2.1.4 and then you can work on the bugs people report from

I'd fully agree if the two problems we are talking about
were not this damn obvious. The ClickTime problem broke
about 25% of the setups and perhaps 75% or more of the
users will see the module path issue.

Anyway, 2.1.4 should go out today with either a fast fix
for ModulePath or a big entry in the BUGS file. Paul, will
you make the decision (and the change in the code/BUGS file)?
The top priority must be to have 2.1.4 today.

Bye

Dominik