Subject: FVWM CVS: fvwm dane

From: CVS <[email-masked]>
Date: Wed, 10 Mar 1999 22:28:01 -0600 (CST)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	dane	99/03/10 22:28:00

Modified files:
	modules        : ChangeLog 
	modules/FvwmForm: ReadXServer.c 

Log message:
* FvwmForm/ReadXServer.c (ToggleChoice): You can now paste multiple
lines into a form.  If the form contains buttons activated by
the Return Key the paste can activate the button.

* FvwmForm/.FormFvwmTalk.: Changed the built-in form to reset the
command field on Return key, necessary for pasting many lines to
look right.  Not the best for typing a line at a time, there is
no feedback.  Pasting lots of config lines at once works well.

--
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: Steve Robbins <[email-masked]>
Date: Thu, 11 Mar 1999 08:44:42 -0500 (EST)

Hi,

Am I the only one disturbed by FVWM installing "hidden" files?  For
exaple, the nifty forms of FvwmForm are in files like .FormFvwmTalk.  

Is there no way for these to be given regular filenames?  If so, I think
we should make it the default.  People using prefix=/usr/local (or just
/usr!) are going to be terribly surprised to see all kinds of .FormFvwm*
files in /usr/local/etc!

--
Steve Robbins                              <[email-masked]>

I am an anarchist.  
I am the antichrist.

---

From: Dan Espen <[email-masked]>
Date: Thu, 11 Mar 1999 09:22:41 -0500

> exaple, the nifty forms of FvwmForm are in files like .FormFvwmTalk.  

So far you are the only one.

> /usr!) are going to be terribly surprised to see all kinds of .FormFvwm*

I think I see your point.  Would it be any better if the files were in
/usr/local/etc/fvwm?  What is the right way to do that?

The leading dot is hard coded.  The command:

FvwmForm FormFvwmTalk. causes FvwmForm to issue the command:

read .FormFvwmTalk.
     ^

I felt the leading dot made sense for config files stored in the users
home directory.  The  way  "read"  works led  me  to  extend this   to
/usr/local/etc.

I know we  have to do  something regarding the potential proliferation
of fvwm2 config files scattered around the users home directory.  That
is,  store them in a  ".fvwm"  or $HOME/$FVWM_CONFIG subdirectory.  So
far, I'm  just trying to get together  enough config files to make the
effort worthwhile.  That could be a reason to drop the leading dot.

I'm open to changing any part of this.

On a  similar subject...I've never  installed AfterStep,  but it looks
like it has  a fairly elaborate   built in config system.  Perhaps  we
would be   smart to steal some  other  window manager's config system,
rather than  building one from  the ground  up.  At least  we would be
creating something familiar to some group of users.

I'd be interested in any opinions about  which config system is around
that is worth starting with and bending to our needs.

--
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: Tim Phipps <[email-masked]>
Date: Thu, 11 Mar 1999 14:33:16 +0000

> /usr!) are going to be terribly surprised to see all kinds of .FormFvwm*

I think we could enhance the read command to be a bit smarter if it
fails to read a file name begining with dot.

How about read trying the following files

for /ANYTHING
  try /ANYTHING only

for ANYTHING (with no leading dot)
  try ./ANYTHING, $HOME/ANYTHING, $SYSCONF/ANYTHING

for .ANYTHING
  try ./.ANYTHING, $HOME/.ANYTHING, $HOME/.fvwm/ANYTHING,
$SYSCONF/ANYTHING

That way the install would create /usr/local/etc/FormFvwmForm and the
user could over ride it by having a .FormFvwmForm or a
.fvwm/FormFvwmForm.  The /usr/local/etc files wouldn't be hidden and the
user could have a .fvwm directory to keep all these files in.  I guess
the files saving stuff would also have to be changed (sorry Dan) to try
to create $HOME/.fvwm/$FILE first and if that failed (probably because
the user doesn't have a .fvwm directory) it could try creating
$HOME/.$FILE

Cheers,
Tim.

---

From: [email-masked] (Paul D. Smith)
Date: 11 Mar 1999 10:23:16 -0500

>> /usr!) are going to be terribly surprised to see all kinds of .FormFvwm*

I agree; installing .xxx files in system directories is really almost
unheard of.

What have we decided (if anything) about installing a system.fvwmrc?
Where does that go?  I guess I thought it would go in the same directory
as the modules, not $SYSCONF, since there's a good chance it'll change
between versions.  Maybe we need to enhance the read-in of this, too, to
allow for site-specific versions to override the basic versions (kind of
like the Emacs site-lisp vs. lisp directories)?

For example, maybe we look for $SYSCONF/ANYTHING, then
$LIBEXEC/fvwm/$VERSION/ANYTHING, and we automatically install into the
latter?

I guess to be _really_ correct, system.fvwmrc, etc. belongs in $DATADIR,
not $LIBEXEC.  Sigh.  Well, as long as they're small it's probably no
big deal :)

  tp> I think we could enhance the read command to be a bit smarter if it
  tp> fails to read a file name begining with dot.

  tp> How about read trying the following files

  tp> for /ANYTHING
  tp>   try /ANYTHING only

  tp> for ANYTHING (with no leading dot)
  tp>   try ./ANYTHING, $HOME/ANYTHING, $SYSCONF/ANYTHING

  tp> for .ANYTHING
  tp>   try ./.ANYTHING, $HOME/.ANYTHING, $HOME/.fvwm/ANYTHING,
  tp> $SYSCONF/ANYTHING

This sounds like a good solution to me.  It does make things potentially
more complex to figure out for the user, though.  Maybe we should have
some kind of logging that prints out what files are being read, with
complete pathnames--maybe even prints out what files are looked for but
not found, so users can see the algorithm "in action".

Whatever it is, we need to document it very clearly in the man page :-/.

-- 
-------------------------------------------------------------------------------
 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.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: Steve Robbins <[email-masked]>
Date: Fri, 12 Mar 1999 01:16:19 -0500 (EST)

On 11 Mar 1999, Paul D. Smith wrote:

> between versions. 

Ick!!  The configuration language won't change _that_ drastically between
releases, one hopes!  

Since it is a configuration file, I think sysconf is a good place for it.
If we go to a scheme with multiple config files, then maybe $sysconf/fvwm
is the place for them.  But I don't think we really need this (yet).

These forms of FvwmForm don't seem like configuration files to me.  They
seem more akin to scripts, are they not?  (I haven't actually played
around with them.  Are these designed to be used as-is, or are they
examples?) 

In any case, they appear to be sharable across architectures, so wouldn't
one want them in /usr/local/share/fvwm?  (i.e. $datadir/fvwm)

> not $LIBEXEC.

Well, the system config file may differ across different architectures at
one installation -- like at our lab :-( -- so I'd not like it in $datadir.
But the forms appear to be shareable.

> more complex to figure out for the user, though.

Yeah, and such complexity bothers me.  For instance, why is "anything" 
treated differently than ".anything"?  Also, I wonder if it is useful to
look in the current directory at all.  Who is starting their window
manager anywhere OTHER than $HOME?

If I wanted to put my config files into $HOME/.fvwm/XXX, couldn't I just
use "Read .fvwm/XXX" in the initial .fvwmrc file?  In other words: why
hardcode this path if I can get the same effect by specifying it
explicitly?

---

From: Steve Robbins <[email-masked]>
Date: Fri, 12 Mar 1999 01:22:55 -0500 (EST)

> that is worth starting with and bending to our needs.

I was really impressed with FvwmScript, actually.  I haven't sat down yet
to figure out the scripting language, but it appears to be more powerful
than just simple forms.  There are conditionals, at least.

There are some configuration-type scripts included in the Scripts
directory, and another more intricate example was posted here by Eddy J. 
Gurney last November. 

I have been musing to myself about building a GUI configure tool for FVWM
from this.  Eddy: any thoughts about this? 

Don't know what I want, but I know how to get it.

---

From: Jay Kuri <[email-masked]>
Date: Fri, 12 Mar 1999 08:45:05 -0500 (EST)

> hardcode this path if I can get the same effect by specifying it

	This is exactly what I do.  My config is split up, but I have Read
.fvwm/blah in there.  Never even had to think twice about it.

Jay

---

From: Dan Espen <[email-masked]>
Date: Fri, 12 Mar 1999 09:37:18 -0500

> .fvwm/blah in there.  Never even had to think twice about it.

Hmm...enough  opinions  have  flown   back and  forth,   that  I  have
completely lost track.

I'm not following this last  part of the thread,  I understand that  a
user can put config files anywhere, but I think the subject at hand is
where fvwm2 puts its config files.

There has been some disagreement about datadir vs. sysconfdir.

There  is a schemes  proposed for writing  files $HOME/.fvwm without a
dot or if .fvwm is missing, writing the files with  a dot.  This makes
some sense, although it doesn't seem proactive  enough.  The user gets
fed up with  all our config files  in the $HOME directory, he  reports
the problem, and  we tell him to  do a mkdir, and move  his files?  Or
was   the  proposal for      fvwm2  to create  the    .fvwm  directory
automatically?

I'm not so sure about this dot flipping, I think it can get needlessly
complicated.  I thought if we install  dot files into etc/fvwm instead
of etc directly no one would care if  the files had  the dot.  Besides
that,  I don't think  we want to spread  our config files all over etc
anyway.   However installing into etc/fvwm  doesn't seem to be default
behavior and I'm not sure how I would make it that way.

---

From: Steve Robbins <[email-masked]>
Date: Sat, 13 Mar 1999 17:44:35 -0500 (EST)

> Hmm...enough  opinions  have  flown   back and  forth,   that  I  have

Yeah, a couple of things did get mixed together.
 
> where fvwm2 puts its config files.

OK, let's focus on system config files, then.

> dot or if .fvwm is missing, writing the files with  a dot. 

Uh...  If we're talking about _installing_ system config files, then I
definitely *don't* want the FVWM install writing them into
$HOME/anything!!

If you're talking about something else, then I'm completely lost.

> of etc directly no one would care if  the files had  the dot.

Actually I do care.  I think config files should *never* begin with a dot. 
Ever.  No matter where they get installed. 

Dotfiles in system directories are too easy to forget about, and get
surprised by later on.  (It happens to me, at any rate.)

> Besides
> anyway.

Part of the problem is the unresolved issue of whether the files in
question are CONFIG files or SCRIPT files.

Certainly "system.fvwm2rc" is a config file.  Admins will want to
customize it.  Often (?) people will customize it on a per-machine basis. 
I do this, at any rate: I use winterms on SGIs instead of xterms (IRIX
xterms use huge fonts by default, which I haven't yet learned how to
cure). 

Thus system.fvwm2rc belongs in the $sysconfdir.  Whether it goes directly
into $sysconf, or into $sysconf/fvwm is a matter of how many config files
we install.  If system.fvwm2rc is the only one, it belongs directly in
$sysconfdir.

The other files in question are the forms for FvwmForms.  Are these config
files?  Will site admins want to customize them?  On a per-machine basis? 
I dunno for sure, but the samples currently in the repository look pretty
generic to me. 

They _look_ more akin to a script, to me.  My feeling is that we ought to
treat them as scripts; i.e., as data shareable across architectures.  If
you buy this argument, they don't belong in $sysconfdir at all, but rather
in $datadir.  In $datadir/fvwm, in fact, since we're installing many
files.  BUT NO LEADING DOTS, PLEASE!  :)

Don't play cards with the Devil.  He'll deal you an awful hand.

---

From: Dan Espen <[email-masked]>
Date: Mon, 15 Mar 1999 12:41:12 -0500

> If you're talking about something else, then I'm completely lost.

Now I'm guilty of talking about 2 things at once and not keeping
the distinctions clear.

> surprised by later on.  (It happens to me, at any rate.)

OK, I use XEmacs to look at so many things, that the hidden file issue
is slow to sink in.  I've got it now.

> files.  BUT NO LEADING DOTS, PLEASE!  :)

The forms are different from system.fvwm2rc in  that we are installing
them.  I  think they are usable  as is, and it would   be folly for an
administrator  to modify them and not  change the name, as our install
will "correct" any modifications the administrator makes.

I do envision individual users making  copies in their home directory,
under the same name.  This is what led me to include the dot.  I think
this ability is necessary.  As  we get more  and more configuration in
place,  there  will be  the need  to  override parts of  it.  Maybe we
should just  ignore this issue and  change read  to search $HOME/.fvwm
first.

I think they are in datadir,  but not in  $datadir/fvwm.  I'm not sure
why our configure script isn't creating  a fvwm directory to drop them
into.

I'm not sure how to accomodate having the same file in $HOME with dots
and $datadir  without dots.  If I change  the read function, I will be
changing existing  behavior.  That  change  won't affect  me...maybe I
don't  care.  Again,  a non-issue if  $HOME/.fvwm is  made the default
location.

If I get around to it, I'll be adding another form soon, probably with
a leading dot.  (I'll clean up the mess soon.)

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]

---

From: Steve Robbins <[email-masked]>
Date: Mon, 15 Mar 1999 21:02:18 -0500 (EST)

> them. 

Ah, but that will change!  I'm about to write an install rule to install a
suitably-generic system.fvwmrc *if and only if* the system does not
already have one.  This should make first time installers happy, and not
bother the rest of us.

> I  think they are usable  as is, and it would   be folly for an

So we agree, then, that they ought to be put into $datadir.  Great!
 
> should just  ignore this issue and  change read  to search $HOME/.fvwm

Ugh.  I know that people will be really unhappy with a hardcoded .fvwm.

> why our configure script isn't creating  a fvwm directory to drop them

Because we didn't write it that way?  :-)
 
> don't  care.  Again,  a non-issue if  $HOME/.fvwm is  made the default

I think this begs the question: why are the forms written in fvwm
configurease?  

Why not have the config file say things like:

AddToMenu Module-Popup  "FvwmModules"   Title

...
+                       "Form - Rlogin"      Module FvwmForm Rlogin.form

And stick the form definition into "Rlogin.form"?  The module can search
for this file however it likes -- independent of fvwm's ReadFile()
function.

This is simple for the user to override with "FvwmForm .Rlogin.form" or
"FvwmForm .fvwm/Rlogin.form", as they see fit.

Perhaps the module would also have a "*FvwmFormPath" option to set a
search path.  

This is not a locker room, and that's a surfboard, not a yacht.

---

From: [email-masked] (Paul D. Smith)
Date: 16 Mar 1999 10:38:51 -0500

%% Steve Robbins <[email-masked]> writes:
 
  >> I do envision individual users making copies in their home
  >> directory, under the same name.  This is what led me to include the
  >> dot.  I think this ability is necessary.  As we get more and more
  >> configuration in place, there will be the need to override parts of
  >> it.  Maybe we should just ignore this issue and change read to
  >> search $HOME/.fvwm first.

  sr> Ugh.  I know that people will be really unhappy with a hardcoded .fvwm.

?? Why?

Aren't all user config directory names hardcoded?

---

From: Dan Espen <[email-masked]>
Date: Tue, 16 Mar 1999 14:32:34 -0500

> Aren't all user config directory names hardcoded?

These are:

  /u/dane:
  drwx------ dane Jun 16  1997 .cooltalk
  drwxr-xr-x dane Jan 22 14:00 .dt              (cde)
  drwx------ dane Apr 23  1996 .fm              (Solaris file manager)
  drwxrwxr-x dane Dec  8 15:47 .fullcircle      (Netscape problem capture)
  drwxrwxr-x dane Oct 15 14:41 .gimp
  drwxrwxr-x dane Sep 30  1997 .hyperb
  drwxr-x--- dane May  1  1998 .lrom            (HP help viewer)
  drwx------ dane Mar  8 08:43 .microsoft       (Exploder)
  drwx------ dane Jan 12  1996 .mosaic-personal-annotations
  drwxrwxrwx dane Mar 16 10:20 .netscape
  drwx------ dane Mar 17  1998 .prognet         (RealPlayer)
  drwxr-xr-x dane May  2  1997 .wastebasket     (Solaris file manager)
  drwxr-xr-x dane Aug 11  1998 .xmcdcfg         (xmcd)

So after my extensive research,  I guess hard coded config directories
are pretty common.

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

---

From: Dan Espen <[email-masked]>
Date: Tue, 16 Mar 1999 22:41:19 -0500

> > I guess to be _really_ correct, system.fvwmrc, etc. belongs in $DATADIR,

If you install system.fvwmrc, by definition, it has to be installed
in FVWM_CONFIGDIR, or the "read" command isn't going to find it.
Currently FVWM_CONFIGDIR is what configure is calling $SYSCONF.

> But the forms appear to be shareable.

They may be shareable, but they are being read with the fvwm2 "read"
command, so unless someone comes up with another idea, I think I have
to move them back to FVWM_CONFIGDIR ($SYSCONF).

I think using the "read" command is the right  thing to do to read the
form  definition in  FvwmForm.   They   contain module  commands,  and
regular  fvwm2 commands, and  I thought they should   go thru fvwm2 on
their way to FvwmForm.

> hardcode this path if I can get the same effect by specifying it

The current logic for unqualified names looks to me like 
$HOME/ANYTHING, $SYSCONF/ANYTHING.

There are performance impacts in looking in too many places.

How about:

1. During fvwm2 startup look for a $HOME/.fvwm directory.
If found, "export FVWM_USERHOME=$HOME/.fvwm/"
otherwise, "	export FVWM_USERHOME=$HOME/".

2. Change "read" to read $FVWM_USERHOME/ANYTHING, $SYSCONF/ANYTHING.

3. Extra credit, a command that sets $FVWM_USERHOME.

The current "save" logic in FvwmForm is an "echo" in a shell.
Having the environment variable, makes it pretty easy to write
in either place.

---

From: Dan Espen <[email-masked]>
Date: Tue, 16 Mar 1999 23:24:55 -0500

> otherwise, "	export FVWM_USERHOME=$HOME/".

Oops, that last part should be: "export FVWM_USERHOME=$HOME."

> 2. Change "read" to read $FVWM_USERHOME/ANYTHING, $SYSCONF/ANYTHING.

And this part should be: $(FVWM_USERHOME)ANYTHING, $SYSCONF/ANYTHING.

That is, deal with the dot and the subdirectory with the same
mechanism.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 22 Mar 1999 17:12:20 +0000

> That is, deal with the dot and the subdirectory with the same

This looks fine by me.
Cheers,
Tim.