Subject: new module: FvwmRearrange

From: [email-masked]
Date: Mon, 9 Nov 1998 13:24:28 +0100

I have merged FvwmTile and FvwmCascade to form a new
module called FvwmRearrange. If 'FvwmTile' and 'FvwmCascade'
are links to the new executable they behave exactly as the
old modules before.

Steve, I didn't know how to create symbolic links with
in Makefile.am. Could you do this?

  FvwmTile -> FvwmRearrange
  FvwmCascade -> FvwmRearrange
  FvwmTile.1 -> FvwmRearrange.1
  FvwmCascade.1 -> FvwmRearrange.1

I didn't add the new module to the distribution. So could you
put it in and remove FvwmTile and FvwmCascade the same time 
please?

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: Steve Robbins <[email-masked]>
Date: Tue, 10 Nov 1998 07:31:52 -0500 (EST)

> are links to the new executable they behave exactly as the

Cool.  

I had to put in a

	#include "config.h"
line.

>   FvwmCascade.1 -> FvwmRearrange.1

OK, the symlinks are made during build.  However, they may be installed as
real files, not symlinks.

> put it in and remove FvwmTile and FvwmCascade the same time 

OK, I have modified the makefiles so that 

	modules/FvwmTile
	modules/FvwmCascade
and also
	textures
	extras/fvwmperl
	extras/fvwmpython

are NOT built and are NOT part of the distribution (make dist).  

I've left them in the CVS tree for now, in case someone really objects and
we need to put them back.  Please DON'T rename them to "old-something", or
put them in some other directory, because it messes up the CVS tree
forever. 

--
Steve Robbins                              <[email-masked]>

I'm a member of the Elvis Death Cult.

---

From: [email-masked] (Paul D. Smith)
Date: 10 Nov 1998 09:34:50 -0500

%% [email-masked] writes:

  dv> Steve, I didn't know how to create symbolic links with
  dv> in Makefile.am. Could you do this?

  dv>   FvwmTile -> FvwmRearrange
  dv>   FvwmCascade -> FvwmRearrange
  dv>   FvwmTile.1 -> FvwmRearrange.1
  dv>   FvwmCascade.1 -> FvwmRearrange.1

I see Steve tried to do this; it _kinda_ works but not really :)

The current method creates symlinks in the build tree, but when "make
install" is run it _copies_ these to the install directory and that
resolves the symlink and copies the binary.  So, you end up with 3
distinct files with identical contents in your install directory.

Steve, I think you're going to have to write a special-case install rule
to handle this, rather than allowing automake to do it.  You can define
a rule in Makefile.am like:

  install-exec-local:
            ...normal make script here...

which automake will see and automatically hook up to be run when
install-exec is run (see the manual for automake) and you can make
symlinks, etc. in here.  You don't even need to make the symlinks in the
build directory at all; just create them on installation.

_However_, I'd like to discuss _not_ doing this first :)

I guess I'd just hate to see the distribution become crowded with lots
of these sorts of things.  Can't FvwmRearrange be invoked with an alias
to get the same effect:

  + "I" FvwmRearrange FvwmTile

or something?  (If not, shouldn't it? :)  If so, I guess I'd prefer that
we document this in the NEWS file as the correct way to fix older setups
rather than installing links.

My $0.02.

-- 
-------------------------------------------------------------------------------
 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, 10 Nov 1998 10:00:31 -0500 (EST)

On 10 Nov 1998, Paul D. Smith wrote:

: _However_, I'd like to discuss _not_ doing this first :)
: 
: I guess I'd just hate to see the distribution become crowded with lots
: of these sorts of things.  Can't FvwmRearrange be invoked with an alias
: to get the same effect:
: 
:   + "I" FvwmRearrange FvwmTile
: 
: or something?  (If not, shouldn't it? :)  If so, I guess I'd prefer that
: we document this in the NEWS file as the correct way to fix older setups
: rather than installing links.

I think it is important to have the links so that people cn continue to use
there existing .fvwm2rc files without having everything break under them.
There is a huge installed base to deal with.

However, I also think that your suggestion is correct, and should be added
so that as new startup files are written, they can be done without
dependancy on the links. Then at a later day (like a year) it can be
dropped. 

I think that once a good "themes" infrastructure is in place in the
distribution it will be alot easier to switch.

The NEWS should say "convert before it is to late!".

Randall

---

From: [email-masked]
Date: Tue, 10 Nov 1998 17:44:53 +0100

> There is a huge installed base to deal with.

That's why I built in this behaviour with symlinks.

> dependancy on the links. Then at a later day (like a year) it can be

I didn't think I had to mention it explicitly: You can *of course*
call FvwmRearrange to get both effects. If invoked as

  FvwmRearrange -tile ...

it behaves like FvwmTile, if invoked as

  FvwmRearrange -cascade ..

it behaves like FvwmCascade :-)

Bye

Dominik

---

From: Steve Robbins <[email-masked]>
Date: Tue, 10 Nov 1998 07:31:52 -0500 (EST)

Cool.  

I had to put in a

	#include "config.h"
line.

	modules/FvwmTile
	modules/FvwmCascade
and also
	textures
	extras/fvwmperl
	extras/fvwmpython

---

From: Steve Robbins <[email-masked]>
Date: Wed, 11 Nov 1998 10:56:47 -0500 (EST)

Hi all,

Since this has caused a bit of discussion, let me explain my reasoning,
and make a new proposal about how to handle the obsoleted modules.

> to handle this, rather than allowing automake to do it.

Yep, I knew about install-exec-local.  I don't know how to use it without
putting in all the gobbledy-gook that automake & autoconf generate: 
DESTDIR, name mangling, etc.  I suppose it really isn't as bad as I
thought, and I could put it in, but I'm worried about it breaking in a
future revision of automake or autoconf. 

But see below for an alternate plan.

> build directory at all; just create them on installation.

Right.  I created the symlinks in the build directory in case it is useful
to test fvwm and its modules from the build directory.  Maybe it's not
even possible to do so, but it should be. 

> of these sorts of things.

Yeah, I have to agree here.  I'd rather document the fact that it was
replaced and let people change their configurations.  The deleted modules
(FvwmCascade and FvwmTile) don't even appear in the current sample
system.fvwm2rc files, so maybe they are only marginally used. 

> There is a huge installed base to deal with.

Yes, this is an important consideration, and it's why I went against my
preferences and put the links in.

On Tue, 10 Nov 1998 [email-masked] wrote:

> On Tue, 10 Nov 1998, Randall S. Winchester wrote:

> > dependancy on the links. Then at a later day (like a year) it can be

I'm all for documenting the change, and dropping the modules later.
However, I suspect that perhaps people won't read the docs and STILL be
surprised a year later ;-)  And that a year from now we will be having the
same discussion, and the modules will never go away.

The current sample configs use neither Cascade nor Tile.  Anyone know how
long this has been the case?  Maybe for these two modules, we can just
drop them now and document that fact?

> it behaves like FvwmCascade :-)

Great!  So as an alternative to making a symlink, we could install a small
shell script that goes like:

	#!/bin/sh
	echo >2 "FvwmTile is obsolete; it has been replaced by FvwmRearrange."
	echo >2 "Please change your configuration file."
	exec @moduledir@/FvwmRearrange -tile $@

If it printed this message at every startup, it would be harder to ignore
than a note buried in NEWS that the modules are going away.  Thus, it
would be easier to actually get them removed in a years time.

Of course, people who dump the X11 startup output into .xsession-errors or
whatever *still* wouldn't see this message.  Does fvwm have a module that
could flash up a notice in a dialog box instead?  Something like xmotd?

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

---

From: [email-masked]
Date: Wed, 11 Nov 1998 19:30:40 +0100

On Wed, Nov 11, 1998 at 10:56:47AM -0500, [email-masked] wrote:
> ---- snip ----

I agree in all details and recommend doing it as Steve proposed.

> could flash up a notice in a dialog box instead?  Something like xmotd?

Nothing I know of.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Wed, 11 Nov 1998 13:38:50 -0500

> > could flash up a notice in a dialog box instead?  Something like xmotd?

FvwmForm can create a popup.
It might not look too nice, (double spaced), but it will do it.

Somehow I think the user will come accross  the message in the session
errors file  sooner or later.  I actually  "tee" the fvwm2 output to a
file and the console.

--
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]
Date: Wed, 11 Nov 1998 20:07:57 +0100

> FvwmForm can create a popup.

Okay, but some builtin method would be better.

Bye

Dominik

---

From: Richard Lister <[email-masked]>
Date: Wed, 11 Nov 1998 14:11:45 -0500

On Wed, 11 Nov 1998 13:38:50 -0500
Dan Espen <[email-masked]> 

--- snip snip ---
> errors file  sooner or later.  I actually  "tee" the fvwm2 output to a

You could start fvwm from xsession, which will then display all the
output for you to see. Helps immensely when switching between different
WMs or binaries as well.

(Get it from somewhere like this
  ftp://sunsite.unc.edu/pub/X11/contrib/applications/).

Which brings me to my bug report :-)  I built Nov 10 version from CVS, and
ran into a growing-window problem with xsession. (This is on RedHat linux,
2.1.125, X11R6.3).

With no WM or some other WMs (can't remember which, but probably twm and
some other derivatives) xsession autoraises even when it doesn't have
focus. This is correct behaviour when there is no WM, so it is always
on top and accessible to start a WM.

Under fvwm-2.0.46 and earlier, xsession behaved like any other window.
Under the new beta it autoraises, but also grows a few pixels in both
directions from bottom right every couple of seconds. The position of the
window remains unchanged. I suspect this is related to the recapture bug.

I have no time to investigate this further at the moment (work, etc, ...).
Maybe at the weekend.

Ric

Richard J Lister, Georgetown Institute for Cognitive and Computational Sciences
Georgetown University Medical Center, Washington, DC 20007, USA
Phone: +1 202-687 2878
Email: [email-masked] 
Web: http://www.giccs.georgetown.edu/~ric/
--
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: 11 Nov 1998 11:29:31 -0500

%% Steve Robbins <[email-masked]> writes:

  >> Steve, I think you're going to have to write a special-case install
  >> rule to handle this, rather than allowing automake to do it.

  sr> Yep, I knew about install-exec-local.  I don't know how to use it
  sr> without putting in all the gobbledy-gook that automake & autoconf
  sr> generate: DESTDIR, name mangling, etc.  I suppose it really isn't
  sr> as bad as I thought, and I could put it in, but I'm worried about
  sr> it breaking in a future revision of automake or autoconf.

Well, yes, but I'd rather do that than have the modules duplicated.  If
it breaks we'll have another excuse to take it out :)

  >> of these sorts of things.

  sr> Yeah, I have to agree here.  I'd rather document the fact that it
  sr> was replaced and let people change their configurations.  The
  sr> deleted modules (FvwmCascade and FvwmTile) don't even appear in
  sr> the current sample system.fvwm2rc files, so maybe they are only
  sr> marginally used.

I guess we need to decide how "backward compatible" we want to be from
release to release.  I personally don't have any problems requiring
these kinds of simple changes to users' config files, as long as they're
well-documented in the NEWS file.  For example, Emacs makes
non-compatible changes all the time and it's much more widely used than
fvwm :).

Also, the fact that this is the first _official_ fvwm 2.x stable release
should give us a _little_ leeway :).  And, I just don't see that many
people using these modules that it would be a huge burden.

But, I don't care that much either way (except I do care that we install
symlinks and not full copies of files :).

---

From: Dan Espen <[email-masked]>
Date: Thu, 12 Nov 1998 08:06:20 -0500

> non-compatible changes all the time and it's much more widely used than

Well, I vote for "as backward compatible as  possible".  I don't think
we can put Emacs users  and fvwm2 users in the  same category.

In  the  case of Tile/Cascade  I  happened  to globally  configure its
menus, so I'm not concerned.  But I think developing the technology of
installing module and even man page links may pay off in the future.

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

---

From: "Randall S. Winchester" <[email-masked]>
Date: Thu, 12 Nov 1998 12:29:42 -0500 (EST)

On Thu, 12 Nov 1998, Dan Espen wrote:

: [email-masked] (Paul D. Smith) writes:
: > %% Steve Robbins <[email-masked]> writes:
: > I guess we need to decide how "backward compatible" we want to be from
: > release to release.  I personally don't have any problems requiring
: > these kinds of simple changes to users' config files, as long as they're
: > well-documented in the NEWS file.  For example, Emacs makes
: > non-compatible changes all the time and it's much more widely used than
: > fvwm :).

This is also why we have to carry three version of emacs around at all
times. Makeing 50,000 users do an editor switch-a-roo is evil (yoh Stallman
you listening?). 

For me, the problem is not "simple changes to users' config files", but
rather changes to global defaults across many platforms (1000+ machines).

I am strongly apposed to random (release-by-release) incompatibilities. It
does not scale. This sort of thing should be done very carefully. If well
desigend, this should rarely become a problem.

You should save the incompatibilities for Major number releases. New
features should be acceptable, but an "old" config file should still be able
to run between most revisions.

: Well, I vote for "as backward compatible as  possible".  I don't think
: we can put Emacs users  and fvwm2 users in the  same category.

Absolutly!

Randall

---

From: Jason L Tibbitts III <[email-masked]>
Date: 12 Nov 1998 12:32:58 -0600

>>>>> "RSW" == Randall S Winchester <[email-masked]> writes:

RSW> You should save the incompatibilities for Major number releases. New
RSW> features should be acceptable, but an "old" config file should still
RSW> be able to run between most revisions.

Of course, there is the argument relating to beta releases, but I don't
think anyone buys that.  There's also the question of whether 2.2.0 will be
a 'major' release.  I think it probably qualifies as much as anything else.

Perhaps we need a version specifier somewhere in the the config file.

 - J<