Subject: FVWM: .fvwmrc file

From: [email-masked] (Mr. Graeme McCaffery)
Date: Mon, 25 Sep 95 13:34:53 BST

I have mentioned this before, but my wish for fvwm is to have the
DEFAULT config file split into sections, to make it easier for
individual users to change things like style without having to copy the
entire .fvwmrc file. This would make it easier for novice users to debug
faults in their configuration.

Another advantage to this system, would be that it would allow modules
to be written easily by different people, that could change the
configuration of fvwm, in keeping with the modular structure of fvwm.
I reckon that most users already split their files and use M4 or CPP to
sort their files, but this takes a bit of knowledge, so setting it as
standard would help newbies.
For those who already like the one file config, the -f option would
allow them to continue as normal.

I propose a system fvwm directory with

Style
mouse
module
function
popup
etc files

and a home fvwm directory as defaults

the user would then be free to only edit those files as needed and would
save system's admin and fvwm mail lists a lot of hassel.
lots of people do this in practice, I ask that it becomes standard.
-- 
>From Mr. G. McCaffery 

email: [email-masked]

snail mail: University of Birmingham
	    School of Electrical &
            Electronic Engineering
	    Birmingham
	    B15 2TT
--
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].

---

From: [email-masked] (Todd Fries)
Date: Mon, 25 Sep 1995 09:03:06 +0000 (GMT)

> allow them to continue as normal.

I think this is a neat idea, as I can't see anything bad about this other than
we have to edit multiple files instead of getting lost looking through one huge
file...

One thing that I think would be an added touch of 'usefulness' would be for
.fvwm to possibly 'stat' files periodically, and if their date has changed
since it last read the file(s), it would re-read them in?

Maybe this is not a good idea, for I haven't taken the time to understand
exactly what M4 or CPP pre-processing is for, but at any rate it's a suggestion
on the table...

While I'm on the subject, is there any particular reason why fvwm must literally
exit and re-run itself to 'restart'?  I mean the program is already in memory,
why waste initialization time when you could potentially just re-run whatever
routine initially parses the .fvwmrc file....not having browsed the source this
also might be a bad idea, but then again...it's an idea...use it as you wish..
-- 
Todd [email-masked]
http://www.cs.umr.edu/~tfries
--
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].

---

From: [email-masked]
Date: Thu, 28 Sep 1995 08:20:31 +0100

> From: "Mr. Graeme McCaffery" <[email-masked]>
> 

In short I disagree. Apart from already having over 100 "dot" files in my home
directory I think that breaking up the configuration file(s) is a bad idea.

I think it may be a better approach to allow the use of a common system config
file (eg /usr/local/lib/fvwm/fvwmrc). This file would be read in as a precursor
to any users' .fvwmrc file.

> faults in their configuration.

I dont think having more files and increasing the complexity will help
newbies. I think the biggest way to help them is to improve the documentation.

-- 
Kit Smithers                                           [email-masked]
-------------------------------------------------------------------------------
--
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].

---

From: <[email-masked]> (Charles Hines)
Date: Thu, 28 Sep 1995 09:03:22 -0400

>>>>> "KitS" == KitS  <[email-masked]> writes:

>> individual users to change things like style without having to copy the

KitS> In short I disagree. Apart from already having over 100 "dot"
KitS> files in my home directory I think that breaking up the
KitS> configuration file(s) is a bad idea.

I agree too.  It's very easy for local installers to set up something
like this if they want, but I don't think it would be a good idea to
break it up by default.

KitS> I think it may be a better approach to allow the use of a common
KitS> system config file (eg /usr/local/lib/fvwm/fvwmrc). This file
KitS> would be read in as a precursor to any users' .fvwmrc file.

Fvwm will already do that now, basically.  You could just tell users
to name their .fvwmrc files something like .fvwmrc-local, and make the
system one be .fvwmrc, which fvwm would read in and it could Read (or
FvwmM4 or FvwmCpp) .fvwmrc-local.

>> faults in their configuration.

KitS> I dont think having more files and increasing the complexity
KitS> will help newbies. I think the biggest way to help them is to
KitS> improve the documentation.

I agree here wholeheartedly.  That and supplying (or pointing to the
sites that have) all of those sample config files.

Chuck

*******************************************************************************
Charles K. Hines
IBM Logic Synthesis developer [BooleDozer (TM)]
and Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

Internet e-mail:     [email-masked]

IBM Internal e-mail: [email-masked]   (preferred from workstation)
                     HINESC at FISHKILL       (preferred from mainframe)
                     HINESC at FSHVMFK1       (discouraged, but I'll get it)

*******************************************************************************
 "dis ting could have possabiwities if I put my twisted widdle mind to it!"
                                                        - Bugs Bunny

 "I have a paper plate in my head because they were all out of the metal ones"
                                                        - Rick Overton
*******************************************************************************
--
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].

---

From: [email-masked] (R. H. Wood)
Date: Thu, 28 Sep 1995 16:30:34 -0500 (CDT)

humm...
didn't the original idea include the suggestion that these multiple-segment
.fvwmrc "files" be put in a "hidden" subdirectory?  like ~/.fvwm/ perhaps?

Elm (the mail reader) already does this.  And I sorta like the idea.  At
first I thought it was a little strange, I suppose because it was the first
"tool" I'd ever used that took that approach. 

But after I got used to it, I really liked it.  It keeps the number of dot
files in the home directory down (I agree that we all seem to wind up with
too many!) and in Elm's case, it provided a place to store away alias 
text and database files needed by some of the features of the tool.

Perhaps fvwm could benefit down the road with having a "place of its own"
to put who-knows-what-have-you stuff that might be needed for future
enhancements/features. 

just another man's $.02 worth (maybe less) ;-)
-- dick
[email-masked]                                      ([email-masked]) 
Richard H. Wood @ Switch Products Division,   DSC Communications Corporation
1000 Coit Road, Office PB1-1526, Mail Stop 121, Plano, TX 75075 214-477-8624   
--
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].

---

From: <[email-masked]> (Charles Hines)
Date: Fri, 29 Sep 1995 08:54:06 -0400

>>>>> "dwood" == R H Wood <[email-masked]> writes:

dwood> humm...

dwood> didn't the original idea include the suggestion that these
dwood> multiple-segment .fvwmrc "files" be put in a "hidden"
dwood> subdirectory?  like ~/.fvwm/ perhaps?

I believe that one of the original suggestions had that, yes.
Regardless, I still don't think that the default should be changed to
this.

All (most?) other window managers have one rc file, and I don't want
to break that tradition just yet.  Fvwm is already powerful enough to
provide this multiple rc file functionalilty if you want, but I don't
think that it should be the default.

Now, if someone out there wanted to provide a sample system.fvmwrc
file to be included that helps facilitate this by reading multiple
local files, along w/ a README about it, I'd be happy to include it in
the sample.fvwmrc directory so everyone that installs it knows that
option is available.  Perhaps I'll take a stab at making one this
weekend, but since I don't split up my rc file, perhaps I'm not the
best one to provide this.

....
dwood> Perhaps fvwm could benefit down the road with having a "place
dwood> of its own" to put who-knows-what-have-you stuff that might be
dwood> needed for future enhancements/features.

dwood> just another man's $.02 worth (maybe less) ;-)

Any ideas are always appreciated and encouraged.

Chuck

---

From: Eli Burke <[email-masked]>
Date: Fri, 29 Sep 1995 10:14:03 -0400 (EDT)

> [email-masked] wrote:

	I definately agree with this. Having been forced to use both
HP's VUE and IBM's PowerDesktop (both very similar.. part of some
idea called the Common Desktop Environment or some such nonsense)
I know how much of a pain in the ass it is to look for things in
multiple multiple files. They have an entire heirarchy of directories
and files to put stuff.
	The only redeeming quality is an x client that allows you to
set a lot of the commonly modified aspects. Changing menus or keybindings,
however, is No Fun.

	But at the same time, having split files, if there are only
two or three and not thirty, could work. I like the idea, but the
particular execution has to be done very carefully. 

-- 
Eli Burke
[email-masked] 
http://csugrad.cs.vt.edu/~eburke/ 
--
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].

---

From: Jan Tellkamp <[email-masked]>
Date: Fri, 29 Sep 1995 16:59:04 +0100 (MET)

You are looking for something to organize a .fvwmrc.
I suggest to have a look at "dotfile", I think, it is worth it.
You can get information @ http://www.imada.ou.dk/~blackie/dotfile/

BTW, thanks to all the guys and girls who build this easy-to-handle powerful
window-manger! It is important to me, because I'm new with unix and X.

Jan

naval architecture:
naval architecture is a science of vague assumptions on debatable figures
taken from inconclusive instruments, performed with equipment of
problematical accuracy by persons of doubtful reliability and questionable
mentality.

---

From: [email-masked] (R. H. Wood)
Date: Fri, 29 Sep 1995 10:52:12 -0500 (CDT)

> multiple multiple files. They have an entire heirarchy of directories

Been there (on the Apollo/HP Vue crap)  and it _is_ a pain; e.g., to
change simple things - like when "providers" of the common environment 
implement things like font choices for xterms in a bizillion different places
instead of using the xresources database settings, and you're like me and 
can't read the damn (small) fonts without getting the bifocals (yes, I'm 
_that_ old, folks) focused on the screen!

> particular execution has to be done very carefully. 

I couldn't have said it better myself.

-- dick