Subject: Overview of setup change

From: Dan Espen <[email-masked]>
Date: Tue, 23 Mar 1999 22:52:34 -0500

This next change has gotten to the point where I'd like to describe
the state its in.

Changes so far:

fvwm.c: remove builtin command table, from function "SetUpRCDefaults"
instead, issue command "read FvwmDefaults".
Export environment variables "FVWM_USERHOME", "FVWM_CONFIGDIR".
FVWM_USERHOME is ".fvwm2/" or ".".

New installed    file "sample.fvwmrc/FvwmDefaults".  Contains commands
from builtin  command table.  All mouse  buttons  on the root activate
the  builtin menu.  The   Help key and F1   on  the root activate  the
builtin menu.  A new  menu entry in  the builtin menu invokes  "Module
FvwmForm FormFvwmHelp.".

New  installed file "sample.fvwmrc/FormFvwmHelp.".  Contains help text
for a new user.  A button invokes the commands:

  "!/bin/cp ${FVWM_CONFIGDIR}/FvwmSetup ${FVWM_USERHOME}fvwm2rc"
  "Restart fvwm2"

New  installed     file    "sample.fvwmrc/FvwmSetup"  is     based  on
system.fvwmrc.   Module  menu invokes  all  the new Fvwmform builtins.
The module  definitions   are separate   files   accessed with  "Read"
commands.

New installed files "sample.fvwmrc/":
FvwmButtonBar, FvwmIconBox, FvwmIconMan, FvwmPager, FvwmWinList,
(so far).  The users .fvwm2rc is created with reads for these files.

Comments:

Right  now, the forms  are in "sample.fvwmrc".   I think they might be
better located in "fvwm" and the appropriate "module" directories.

Exporting the environment    variables   was necessary to    make  the
installation form  work.  I was recently  discussed,  its not  good to
flood the environment with junk.  So far its only 2 new variables.

The   ".fvwm2"  is currently hardcoded.   This    seems to  be  normal
practice.  So  far, the user  creates  the directory from  the command
line.

So far the config file naming convention is:

Forms: "FormFvwmXxx.". Example: "FormFvwmHelp."

Command config files: "FvwmXxx". Example: "FvwmSetup"

Builtin menus: "MenuFvwmXxx". Example: "MenuFvwmBuiltin".

Builtin functions: "FuncFvwmXxx". Example: "FuncFvwmFocusAndWarp".

-- 
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: Dominik Vogt <[email-masked]>
Date: Wed, 24 Mar 1999 12:07:41 +0100

> FVWM_USERHOME is ".fvwm2/" or ".".

I didn't follow this thread, so correct me if I'm saying something
stupid. But won't fvwm screw up completely if it doesn't find its
builtin command table and no other config file? Or it the FvwmDefaults
do not contain at least an exit entry in a menu? This would
completely lock your X server. Since I use some custom installation
procedure I think this will happen on my system if I delete my
.fvwm2rc.

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: Wed, 24 Mar 1999 08:33:47 -0500

> procedure I think this will happen on my system if I delete my

There is no thread yet, this was the first response.

The file "FvwmDefaults" is installed in the "sysconfdir" no matter how
you run  configure.  If a user is  so foolish as  to remove  it, fvwm2
reverts to how it used to behave before we had the builtin menu.  That
is, you can't do anything with it.

I think thats a problem,  but a small  problem.  The advantage is that
you have 2 easily editable  files, "FvwmDefaults" and "FvwmSetup".  If
you are  familiar with the builtin default  setup, the  only thing you
can do with it is "exit".  It even lacks enough bindings to give focus
to a window.  (Or so it seemed to me.)   I'm finding it much easier to
decide what belongs in each file now that they are external files.

I'm guessing that "FvwmDefaults" will  grow considerably now that  its
an external file.

---

From: Steve Robbins <[email-masked]>
Date: Wed, 24 Mar 1999 09:39:03 -0500 (EST)

> This next change has gotten to the point where I'd like to describe

Thanks for the "heads-up", Dan, but I'm afraid that I've gotten lost in
all the discussion. 

Before you commit, could you remind us why you are doing this?  What is
the problem you are trying to solve, and how will these changes help?  It
would be nice to discuss this before commits go in.

>   "!/bin/cp ${FVWM_CONFIGDIR}/FvwmSetup ${FVWM_USERHOME}fvwm2rc"

Any idea if "/bin/cp" works on VMS?

> flood the environment with junk.  So far its only 2 new variables.

Two more environment variables is three too many: remember that we are
working to get rid of FVWM_MODULEDIR.

Environment variables are the run-time equivalent of global variables. 
They are only to be used as a last resort. 

> practice.

I don't know if it is normal practice.  I do not think it is *good*
practice.  One ought to be able to set it.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 24 Mar 1999 15:51:54 +0100

> There is no thread yet, this was the first response.

I meant the config file thread.

> you run  configure.

Duh, I never install fvwm with 'make install' but copy the files with
a script (much easier to adapt). This change will force me to set some
environment variable.

> If a user is  so foolish as  to remove  it, fvwm2

But if you modify this file fvwm might even crash. Some functionalities
absolutely require an initial config command or they will not do what
they should or even coredump. MenuStyle is a good example. The first
MenuStyle command is interpreted to give the default menu style. If
the first MenuStyle command does not use the '*' style you will not
have '*' as the default style. I know there are other commands that
simply cause a coredump (can't remember which).

Perhaps we could leave a minimal builtin config that just initialises
all the necessary structures and can be overridden by the file. But
at least you should be able to terminate fvwm.

> decide what belongs in each file now that they are external files.

I like the idea too, but we can't rely on such a file for the most
basic functionality.

Bye

Dominik

---

From: Tim Phipps <[email-masked]>
Date: Wed, 24 Mar 1999 15:00:10 +0000

> instead, issue command "read FvwmDefaults".
What's the difference between FvwmDefaults and fvwm2rc/system.fvwm2rc?
Why not just remove SetUpRCDefaults and let the default startup file
reading do the work.

> FVWM_USERHOME is ".fvwm2/" or ".".
Could we have ".fvwm/" instead of ".fvwm2/"?  Better yet could fvwm take
note of these variables if they are already set and use them unchanged? 
There would be no need to do a scan for ~/.fvwm/, just use the already
set value if there is one, or export FVWM_USEHOME=".".

These variables only need to be exported for modules don't they?  It
might be better to not export them for Exec's so as not to grow the
users env too much. Same goes for FVWM_MODULEDIR I think.

Cheers,
Tim.

---

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

>> The ".fvwm2" is currently hardcoded.  This seems to be normal

  sr> I don't know if it is normal practice.  I do not think it is *good*
  sr> practice.  One ought to be able to set it.

But _why_?  I just don't see any practical purpose in allowing this to
be configured.  Under what circumstances would you want to change it?
_How_ would you change it?

We don't allow you to change the name of the ~/.fvwm2rc file and no one
seems to care about that; why would we allow changing the name of the
~/.fvwm2 directory?

I don't know of any other app, anywhere, that allows you to customize
the name of the user's config directory or filename (at least not
without changing the source).

-- 
-------------------------------------------------------------------------------
 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: Tim Phipps <[email-masked]>
Date: Wed, 24 Mar 1999 15:16:36 +0000

> simply cause a coredump (can't remember which).

Looking at what's in SetRcDefaults I'd guess that not having XORValue,
DefaultFont, DefaultColors, HilightColor and "style * color ?/?" could
all cause core dumps.

> at least you should be able to terminate fvwm.

Sounds good.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 24 Mar 1999 16:31:38 +0100

> without changing the source).

Er, we can already do it:

  # fvwm2 -f my_config_file

Not that I want to say that we need it as an environment variable.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 10:33:25 -0500

> would be nice to discuss this before commits go in.

Good question.

The part about FVWM_USERHOME lets users get the clutter out of their
home directory.

The part about the Form being invoked from the startup menu automates
the creation of the users .fvwm2rc.

Pulling  the table out  of fvwm.c makes it easier   to change and just
seems like  the right thing to  do.  It slightly   reduces the size of
fvwm2.

Exporting the environment variables  seems like the most expedient way
of letting  commands  like the   "/bin/cp"  below work.   I  also need
FVWM_USERDIR  in  FormFvwmDefaults. and  the FvwmAnimate customization
dialog.

Overall, I'm trying to lay the groundwork for automated customization.

> Any idea if "/bin/cp" works on VMS?

Not a clue.  I thought of implementing some kind of "Write" command
in fvwm2, but something like this seemed preferable.  I believe we
have OS2 users also.  I could use plain "cp" but I don't know yet
if that would help.  The forms default dialog is currently using
"/bin/echo" and "/bin/date".

> They are only to be used as a last resort. 

I agree.  I  tried to get FvwmDefaults to   pass thru "sed" by  making
changes to Makefile.am and got  nowhere.  Any hints would be  welcome.
That would help with FVWM_CONFIGDIR but not with FVWM_USERHOME.

> practice.  One ought to be able to set it.

A while ago I posted a list of all the "dot" subdirectories in my home
directory.    Not one package  gave   me  any control  over what  that
subdirectories name was going to be.

So far,  there is nothing about   the way I've  implemented this, that
wouldn't  let  one change it  by  writing a command  to give  it a new
value.

---

From: Steve Robbins <[email-masked]>
Date: Wed, 24 Mar 1999 10:34:10 -0500 (EST)

On Wed, 24 Mar 1999, Dominik Vogt wrote:

> But if you modify this file fvwm might even crash.

Yeah, I think this is a good point.  The builtin defaults (SetRCDefaults)
were intended as a fail-safe, not as a useful minimum, right?

> at least you should be able to terminate fvwm.

And pull down an xterm!!!

---

From: Steve Robbins <[email-masked]>
Date: Wed, 24 Mar 1999 10:35:45 -0500 (EST)

> What's the difference between FvwmDefaults and fvwm2rc/system.fvwm2rc?

Indeed.

> Why not just remove SetUpRCDefaults and let the default startup file

Better yet: leave a fail-safe compiled in that lets you start an xterm to
fix things, or exit fvwm.

Then install a useful default system.fvwmrc if none already exists.  

--
Steve Robbins                              <[email-masked]>

If I had a rocket launcher, some son of a bitch would die.

---

From: [email-masked] (Paul D. Smith)
Date: 24 Mar 1999 10:42:52 -0500

>> without changing the source).

  dv> Er, we can already do it:

  dv>   # fvwm2 -f my_config_file

I meant to say, the default name.

We could even re-use that switch; just stat the path given with -f and
see if it's a file or a directory.

---

From: [email-masked] (Paul D. Smith)
Date: 24 Mar 1999 10:46:53 -0500

>> FVWM_USERHOME is ".fvwm2/" or ".".

  tp> Could we have ".fvwm/" instead of ".fvwm2/"?

I agree with this.  There's no backward-compatibility issue so we should
use ~/.fvwm.  Plus if everyone starts moving there it'll be that much
less painful if/when we decide to change the config file back to
~/.fvwmrc :)

---

From: [email-masked] (Paul D. Smith)
Date: 24 Mar 1999 10:48:15 -0500

tp> These variables only need to be exported for modules don't they?
  tp> It might be better to not export them for Exec's so as not to grow
  tp> the users env too much. Same goes for FVWM_MODULEDIR I think.

Well, I've already explained numerous times why I want FVWM_MODULEDIR
exported for Exec's :)

---

From: [email-masked] (Paul D. Smith)
Date: 24 Mar 1999 10:52:55 -0500

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

  de> I tried to get FvwmDefaults to pass thru "sed" by making changes
  de> to Makefile.am and got nowhere.  Any hints would be welcome.

Look at the way it's done in fvwm/Makefile.am.  Basically, you specify
that FVWM_CONFIGDIR should be substituted in the configure.in file, then
you use $(FVWM_CONFIGDIR) in the Makefile.am, like:

    -DFVWM_CONFIGDIR=\"$(FVWM_CONFIGDIR)\"

No seds necessary! :)

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 10:56:02 -0500

> > What's the difference between FvwmDefaults and fvwm2rc/system.fvwm2rc?

The  difference is  that  FvwmDefaults will  continue  to be read even
after  the user creates a  .fvwm2rc whereas the  system.fvwmrc is only
read if fvwm2 doesn't find a .fvwm2rc.

> fix things, or exit fvwm.

I seem to be blind to the problem.  If you install fvwm2 correctly,
the file will be there and fvwm2 will read it.  If you don't install
fvwm2 correctly, it doesn't work.

I can't quite envision why one wouldn't install fvwm2 correctly.

The "xterm" part was recently added to the builtin table, I haven't
removed it from FvwmDefaults, but I found I was unable to get the
window to take focus so I could do something with it.  I might
have been doing something wrong.

---

From: Steve Robbins <[email-masked]>
Date: Wed, 24 Mar 1999 10:53:46 -0500 (EST)

> be configured.  Under what circumstances would you want to change it?

Individual taste, for one: see Tim's email on .fvwm versus .fvwm2.

> _How_ would you change it?

On the command line of fvwm.  In the rc file.

I'm not terribly concerned about a SINGLE rc file, such as .fvwmrc.  I
grant you that is common practice.  

However, we seem to be moving into splitting the configuration into a
zillion files.  First of all, I'm not sure exactly what problem we are
trying to solve.  Nor am I convinced this is the best way to solve it. 

If we *do* require a directory to hold a zillion config files, then .fvwm
is a reasonable DEFAULT choice.  But is it so hard to make this
customizable?  I think not. 

> without changing the source).

You may not know about it because it is not commonly done, but trn and
pine allow it.  Pine and elm and trn also allow customizing of the
directories typically called ~/News, ~/mail or ~/Mail.  Etc, etc.  I'm
sure there are others, but that is beside the point.  The point is: why
hardcode if there is a way to make it customizable? 

When I was dead, I wore a strong perfume.
When I was dead, I never left the room.

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 11:02:53 -0500

> less painful if/when we decide to change the config file back to

In this case  I don't care.  I  was going to go  with ".fvwm" until  I
read  Robert   Ford's description   of   his use of   a  configuration
subdirectory that he called ".fvwm2".  I took his post as one vote for
".fvwm2".  Now I see 2 votes for ".fvwm".  Lets assume I am now on the
".fvwm" bandwagon.  How many objections to ".fvwm" are there?

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

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 11:10:58 -0500

>     -DFVWM_CONFIGDIR=\"$(FVWM_CONFIGDIR)\"

Thats   fine for   C  programs, but  in this    case, I  need  to  get
FVWM_CONFIGDIR into a command  generated by a form  file.  Here is the
form file in question:

# FormFvwmHelp. - Help Text for fvwm2
DestroyModuleConfig         FormFvwmHelp.*
*FormFvwmHelp.WarpPointer
# Layout
*FormFvwmHelp.Line    center
*FormFvwmHelp.Text    "fvwm2 - Help"
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    " "
*FormFvwmHelp.Line    left
*FormFvwmHelp.PadVText 0
*FormFvwmHelp.Text    "You are probably displaying the \"builtin\" menu"
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    "because you are starting fvwm2 for the first time"
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    "and have pressed button 1 on your mouse"
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    "while the pointer was on the root window."
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    ""
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    "After you finish setting up fvwm2 you will have"
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    "button 1 on your mouse doing something more useful."
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    "Press the Create Config and Restart button if you"
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    "just want a skeleton .fvwm2rc config file."
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    "You will have to hand edit the skeleton config file,"
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    "but don't worry, there are lots of helpful comments."
*FormFvwmHelp.Line    left
*FormFvwmHelp.Text    ""
# Buttons
*FormFvwmHelp.Line    center
*FormFvwmHelp.Button  quit    "Return - Dismiss"               ^M
*FormFvwmHelp.Command   Nop
*FormFvwmHelp.Button  quit    "F4 - Test Create Config and Restart" F4
*FormFvwmHelp.Command   Exec exec /bin/cp ${FVWM_CONFIGDIR}/FvwmDefaults ${FVWM_USERHOME}fvwm2rc
*FormFvwmHelp.Command   Restart fvwm2

---

From: Steve Robbins <[email-masked]>
Date: Wed, 24 Mar 1999 11:14:50 -0500 (EST)

> read if fvwm2 doesn't find a .fvwm2rc.

Oh I see.  Yes, I think that is a useful thing.  I never did understand
why the startup logic read "system.fvwmrc" OR ".fvwmrc", and not both.
It makes it terribly hard to set useful site defaults and allow users to
override them.

But this begs the question: why invent a new name?  Why not read
system.fvwmrc, then the users .fvwmrc?
 
> I can't quite envision why one wouldn't install fvwm2 correctly.

Nevertheless, people do.  I've done it in the very recent past -- that's
why I stuck in the "xterm" option.  ;-) 

I'd really prefer to have a compiled-in failsafe menu that allows me to
open an xterm and fix my goof.  It would only be used if the defaults file
couldn't be found.

The revolution will not be televised.

---

From: [email-masked] (Paul D. Smith)
Date: 24 Mar 1999 11:19:50 -0500

de> Thats fine for C programs, but in this case, I need to get
  de> FVWM_CONFIGDIR into a command generated by a form file.

Oh.  In that case you should name the file FvwmFormHelp.in, then add it
to the list of AC_OUTPUT(...) files in configure.in.  Then it will be
processed as any other .in file, during configure, and all appropriate
markers replaced during a translation to plain FvwmFormHelp.

Then you can do things in FvwmFormHelp.in like:

  de> *FormFvwmHelp.Command   Exec exec /bin/cp @FVWM_CONFIGDIR@/FvwmDefaults ${FVWM_USERHOME}fvwm2rc

and the @FVWM_CONFIGDIR@ will be replaced by the appropriate value (if
you've called AC_SUBST() on it in configure.in).

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 24 Mar 1999 17:41:33 +0100

> open an xterm and fix my goof.  It would only be used if the defaults file

I *never* install fvwm in the intended way. Why assume the user
know what they do? There are more than enough idiots like me ;-)

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 24 Mar 1999 17:45:59 +0100

> ".fvwm" bandwagon.  How many objections to ".fvwm" are there?

Make it four vote for .fvwm.

Dominik ^_^

---

From: Steve Robbins <[email-masked]>
Date: Wed, 24 Mar 1999 11:46:29 -0500 (EST)

> you've called AC_SUBST() on it in configure.in).

This doesn't work.  FVWM_CONFIGDIR is set to ${sysconfdir}, which is not
known at configure time.  It is only known at build time.  That's why
there are exceptional rules for fvwm/{builtins,fvwm,read}.c that pass
these values in via '-D' options, rather than getting it from config.h.

I think sed is the only possibility in the case of non-C.  For the perl
script FvwmConsoleC, I stole the following from cvs, which I think is
adaptable for Dan's purposes:

FvwmConsoleC.pl: FvwmConsoleC.pl.in
        rm -f $@
        sed -e 's,xPERLx,$(PERL),' $< > $@-t
        mv $@-t $@
        chmod +x $@

(although, come to think of it, the "chmod +x" at the end is unnecessary,
since it is listed in a _SCRIPTS primary)

When love is gone, there's always justice.
And when justice is gone, there's always force.
And when force is gone, there's always Mom.

---

From: [email-masked] (Paul D. Smith)
Date: 24 Mar 1999 12:15:35 -0500

sr> This doesn't work.  FVWM_CONFIGDIR is set to ${sysconfdir}, which is not
  sr> known at configure time.  It is only known at build time.

Oh yah.  I forgot about allowing makefile overrides.  Very important,
though; I do it myself relatively frequently and always curse autoconf
packages which break this kind of thing :)

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 12:58:42 -0500

> set value if there is one, or export FVWM_USEHOME=".".

It seems reasonable to check for the variable before looking for the
directory.  I see we also have an "SM_SAVE_DIR", so this wouldn't be
the first one.

> users env too much. Same goes for FVWM_MODULEDIR I think.

fork(),
in child?
   putenv(),
   exec().

I'll try it.

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 13:13:39 -0500

> hardcode if there is a way to make it customizable? 

To avoid bloat.
To reduce confusion in problem reports.
To avoid mysterious behavior.  (I removed a lot of junk from my .profile,
and now fvwm2 doesn't work.)

Bear in mind that right now, I've agreed to let this be set by way of
an environment variable.

No   one has  addressed the  issue    of how/when this directory  gets
created.  Right  now the  path for  the novice  user is, fvwm2 creates
lots of files in their home directory.  They get frustrated, hopefully
read some documentation,  do a mkdir, move  a bunch of existing config
files,  and restart.  Instead of  thinking about more and more control
over every aspect of  fvwm2 behavior,  I think we  need to  think more
about making things work well automatically.

Maybe I'll add a mkdir option to FvwmSetup.

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 13:53:33 -0500

> It makes it terribly hard to set useful site defaults and allow users to

The crazy thing is, the logic is,
read $HOME/.fvwm2rc,
not found, read $FVWM_CONFIGDIR/.fvwm2rc,
not found, read $FVWM_CONFIGDIR/system.fvwmrc.

So logically, system.fvwmrc should have always been called .fvwm2rc.

> system.fvwmrc, then the users .fvwmrc?

In this list, we previously recognized that some users followed the
instructions at the front of the "system.fvwmrc" and made local
customizations and installed the file.  If we start installing the
file under that name, we are going to break fvwm2 installations
that run without $HOME/.fvwm2rc files.

Besides that, I think we need a new, more consistent naming convention.

As  for the  last part, we  don't   want to  read "system.fvwmrc" then
".fvwm2rc".  We  want to  read "FvwmDefaults"  (or the  builtin array)
then  ".fvwm2rc".  The system.fvwmrc file is  a starting point for the
users .fvwm2rc file.

> open an xterm and fix my goof.  It would only be used if the defaults file

Darn, I still think removing the builtin is a really good idea, and
I appear to be all alone on this one.

Someone agree with me that hardcoding all this junk in fvwm.c
is unnecessary.  There are lots of programs that won't work if you
don't install all their parts.

I intend to remove the need for lots of users to configure the
pager, fvwmident, etc. by having prewritten configs for these modules
in sysconfdir.  They really will need to install fvwm2 correctly
for any of this to work.

Oh well, its not  necessary to remove the  builtin array for  what I'm
doing, but I'm not convinced that the hardcoded table is a good idea.

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 14:06:54 -0500

>         sed -e 's,xPERLx,$(PERL),' $< > $@-t

I had found this and tried to duplicate it, and couldn't get it
to work.  Is there something else going on outside the Makefile.am
that makes this work?

The above rule gets the ".in" file from the source tree to the build
directory.  I believe I ran into problems getting the file from
the build directory into sysconfdir.

What file do I put into the config_DATA list?

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 24 Mar 1999 20:18:29 +0100

> don't install all their parts.

No, I won't agree. We *need* a setup that allows fvwm to come up
and at least allow the user to exit always. I agree that much of
the stuff can be taken out. Crshing or locking up the X server
just because the installation did not work as it should or because
someone took a vital command out of the file is not acceptable
behaviour.

> in sysconfdir.  They really will need to install fvwm2 correctly

I'm not saying the fvwm should run well with a screwed up installation,
but that it must not take down the whole system. With a locked X server
you may even have to unplug the power cord of your machine. And this
only because a single non critical file was damaged.

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 14:18:44 -0500

> a script (much easier to adapt). This change will force me to set some

No it won't, it will force you to copy one or more additional files.
You already have to do that for the FvwmTalk replacement.
Nothing I've done yet forces you to set an environment variable.

The exports that I described above are done by fvwm2.

---

From: Julian Gilbey <[email-masked]>
Date: Wed, 24 Mar 1999 14:55:24 +0000 (GMT)

Snippets only:

> [...]
> [...]
> [...]

Groan.  Is this program called fvwm or fvwm2?  Are we going to call
the config files fvwmrc or fvwm2rc?  Surely the directories should be
then be called sample.fvwm2rc and all files similarly?

FVWM 1.xx never looked in a .fvwm/ directory, so why can't we use that
for the current FVWM by default, maybe looking for a .fvwm2/ directory
if that fails?

[I've just created a Debian version of FVWM 2.2 which uses the
~/.fvwm/ directory to look for "hook files".  I don't particularly
want to have to get everyone to change their stuff in six months' time
when 2.4.0 is released, so it would be great to know whether this use
of .fvwm2/ is intended to remain that way, then I'll make the change
now before too many people have used it.  BTW, the hook files are a
really nice idea: the system.fvwm2rc has a basic structure, with
Read .fvwm/foo.hook commands scattered through it, allowing the user
to customise bits of fvwm2 without having to write their own full
.fvwm2rc.]

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [email-masked]
             Debian GNU/Linux Developer.  [email-masked]
       -*- Finger [email-masked] for my PGP public key. -*-
--
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: Wed, 24 Mar 1999 14:40:57 -0500

Gee,  everywhere  I've  ever   worked we produce   a design  document,
schedule one or  more meetings for review,  etc.  I like this blizzard
of e-mail much better.

The changes I've accepted so far are:

1. Default FVWM_USERHOME to ".fvwm" instead of ".fvwm2".

2. If FVWM_USERHOME is already exported, don't even do a "stat()"
to check for the directory, just use it.

3. Only export the 2 new variables for modules.  (Keep them
out of Exec'ed commands.)

4. Make sure fvwm2 exits or the user can exit if there are no
usable config files around.

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 14:49:31 -0500

> for the current FVWM by default, maybe looking for a .fvwm2/ directory

Don't groan,  after todays discussion, it will default to ".fvwm".

> to customise bits of fvwm2 without having to write their own full

I hope I don't cause you any problems.  The new logic would take
"Read .fvwm/foo.hook" and would look for
"$HOME/.fvwm/.fvwm/hook.foo".
       ^^^^^^^^^^^

Can you control the "Read" commands so that they can be easily changed
to "Read hook.foo"?

---

From: Julian Gilbey <[email-masked]>
Date: Wed, 24 Mar 1999 20:26:57 +0000 (GMT)

> system.fvwmrc, then the users .fvwmrc?

I heartily agree.  The effective setup really ought to be:

 - Read some sort of system defaults, be it in an FvwmDefaults file, a
   system.fvwm2rc file or the like, but only *one* of these; there
   should *either* be a defaults file or a system.fvwm2rc file, not
   both.  What advantage is there in having two configuration files?

 - Then read the user's .fvwm2rc file.

I am also puzzled as to why we need to enforce a myriad of config
files.  A user should surely be able to run FVWM with no config files?
If they wish to configure stuff, let them create the files (as
described in the docs, which our average user *will* read, right? ;).
There should be "sensible" defaults for everything, and the personal
files only modify the defaults, they don't replace them.

So I would envisage system.fvwm2rc being something like:

ModulePath $FVWM_MODULEDIR:/usr/local/lib/fvwm
IconPath /foo/bar:/foo/baz
PixmapPath /foo/bar:/foo/baz

MenuStyle "*" ....

etc., and then the user's .fvwm2rc modifies this.  How does that sound?

And if we wish the user to be able to add things at various points
during the reading of the system.fvwm2rc, we can have commands such as
 Read .fvwm/colours Quiet
at the appropriate points.  (And if we're also catering for Americans,
we can also check for .fvwm/colors ;)

One advantage of the latter approach is that precisely one file needs
changing, both upstream and in individual installations, and that is
the system.fvwm2rc file.  This seems far easier than coding a lot of
stuff into the executable code, and it makes the result far simpler
for sysadmins to modify where necessary.

   Julian

P.S. I also go for .fvwm/ rather than .fvwm2/

---

From: Julian Gilbey <[email-masked]>
Date: Wed, 24 Mar 1999 20:48:45 +0000 (GMT)

> "$HOME/.fvwm/.fvwm/hook.foo".

That bit's easy.  A question I then ask myself, though, is: will this
directory be automatically created?  How much of the stuff in it will
be essential?  Can the user lock themselves in knots by accidentally
deleting any given file from this directory, or, indeed, the entire
directory?  If the answer's "no" to the latter question, I'm happy.

   Julian

---

From: Matthias Clasen <[email-masked]>
Date: Wed, 24 Mar 1999 23:17:40 +0100

> directory.  I see we also have an "SM_SAVE_DIR", so this wouldn't be

But SM_SAVE_DIR is *not* exported - why should it ? 

-- 
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: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 22:06:45 -0500

> But SM_SAVE_DIR is *not* exported - why should it ? 

Sorry, perhaps that sentence isn't clear.

I was referring to the new requirement to read an environment variable
(FVWM_USERHOME), and I was   looking for other  environment  variables
read by fvwm2, and I found this line:

session.c:692:  path = getenv ("SM_SAVE_DIR");

---

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

%% Regarding Re: Overview of setup change;

  >> system.fvwmrc, then the users .fvwmrc?

  jg> I heartily agree.  The effective setup really ought to be:

  jg>  - Read some sort of system defaults, be it in an FvwmDefaults file, a
  jg>    system.fvwm2rc file or the like, but only *one* of these; there
  jg>    should *either* be a defaults file or a system.fvwm2rc file, not
  jg>    both.  What advantage is there in having two configuration files?

  jg>  - Then read the user's .fvwm2rc file.

What if the user has no .fvwm2rc file?

The point of the system rc file is for exactly this case: if the user
has no personal config then it provides some kind of usable setup.  The
user can copy that and modify it as he/she likes.  Note I'm _NOT_
holding up the current system.fvwm2rc files as a good example of this.

I'm not sure why people are confused about why we don't automatically
source system.fvwm2rc.  If all you want to put in there is some default
styles, sure, go ahead, I guess.

But as soon as you start adding anything that might stand for a
replacement of the user's .fvwm2rc file, now you're talking menus, etc.
Then if the user _does_ have a .fvwm2rc file, and both get sourced, he
has to go in and undo all that stuff from the system rc file!  Bogus.

When I write my .fvwm2rc file, I want the menus, etc. I've defined, and
nothing else.  Without a lot of work :).

---

From: [email-masked] (Paul D. Smith)
Date: 24 Mar 1999 14:26:54 -0500

>> users env too much. Same goes for FVWM_MODULEDIR I think.

  de> fork(),
  de> in child?
  de>    putenv(),
  de>    exec().

  de> I'll try it.

Pls. don't, at least for FVWM_MODULEDIR!  Thx.

PS. I think some of these others will be useful to Exec'd commands, too:
    for example FVWM_USERDIR would be very handy for writing generic
    scripts, esp. if the user is allowed to change the thing with the -f
    option or something.  We find $HOME handy, right?

    I still don't really grok the aversion to environment variables, but
    if we really want to get rid of them please provide some equivalent
    way of obtaining that information from a shell script.

    Chuck Hines emailed me and suggested using properties on the root
    window (I lost his email) which could be retrieved with xprop; this
    is a funky idea but it seems too complicated to me--then again, I
    prefer the simplicity of environment variables so what do I know :)

---

From: Tim Phipps <[email-masked]>
Date: Thu, 25 Mar 1999 10:00:39 +0000

> "$HOME/.fvwm/.fvwm/hook.foo".

Don't foget that we're not discussing changes to the way Read treats
absolute paths.  If Julian changes his reads to "Read
$HOME/.fvwm/hook.foo" it will always work no matter what we do to the
read-relative logic.

Just another snow-flake,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Thu, 25 Mar 1999 10:17:52 +0000

> Besides that, I think we need a new, more consistent naming convention.

Agreed, I think what you're doing is great, don't give up.

> is unnecessary.

I would agree if we could be certain that the junk to be removed doesn't
actually prevent any core-dumps/lock-ups in the event that a user starts
fvwm without any rc files or strange rc files.

Take for example the AddToMenu in SetRcDefaults(). One side effect is
that the "+" command has something to add to.  If fvwm didn't execute an
AddTo* before the users rc file did a "+ I Exec xterm" the "+" command
might core-dump on a NULL reference.

I'm not saying that it will, just that we should make sure before
removing stuff.

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Thu, 25 Mar 1999 08:11:49 -0500

> Pls. don't, at least for FVWM_MODULEDIR!  Thx.

I've only applied it to FVWM_USERDIR.

>     prefer the simplicity of environment variables so what do I know :)

I would prefer environment variables over properties also.
If we come up with a use for FVWM_USERDIR in an Exec'd command,
I will move it to a place where its available for Exec's.

I think a  few truly global and useful   environment variables are  no
problem.  Putting them where they are not needed is a problem.

---

From: Steve Robbins <[email-masked]>
Date: Thu, 25 Mar 1999 08:53:49 -0500 (EST)

> about making things work well automatically.

I agree with this last sentiment!

I'm sorry if I'm being really slow about this, but I honestly don't see
the problem we are trying to solve.  I never had fvwm create "lots of
files in my home directory".  In fact, I don't think it created any!  I
created & edited a .fvwmrc file myself. 

Of course, having a monolithic .fvwmrc file is a pain in the ass to
understand or maintain.  So splitting the config into small bits that are
read by the master file is a fine idea.  

However, we can do that already: witness the debian hook scheme.  [What
config scheme does RedHat use?] This is my main objection: as far as I can
see you are adding a feature that already exists, and hardcoding in C
things like the pathname to boot!

I guess I have to ask the question again: what problem are we trying to
solve that *cannot* be solved by existing mechanisms?

---

From: Steve Robbins <[email-masked]>
Date: Thu, 25 Mar 1999 08:56:47 -0500 (EST)

> What file do I put into the config_DATA list?

The one you want to install; i.e., the generated one.  

You probably also have to put the ".in" file into the EXTRA_DIST list, BUT
DON'T PUT THE GENERATED FILE in any _DIST.

I'd rather have one of your minutes
than a year with all the hours in it.

---

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

> created & edited a .fvwmrc file myself. 

Right now you would have .fvwm2rc, .FvwmForm, and .FvwmAnimate,
if you used the features that create them.  It seems to me,
we might be creating a few more.

> things like the pathname to boot!

Are you proposing that fvwm2 adopt the Debian hook scheme?  I would if
I had access to it and  knew what it was.  I  sent mail to this list a
few weeks back  asking if  there was  a good  customization scheme  we
could  adopt, since I  don't  want to create   something if it already
exists.

I don't think I deserve the hardcoding rap.  I think you are referring
to the $HOME/.fvwm directory.  If I hard code it in the first checkin,
its all of 10 minutes work to create a command to change it.  Come to
think of it, I've aleady added a getenv for FVWM_USERHOME so I guess
I don't know what hardcoding you are referring to.

> solve that *cannot* be solved by existing mechanisms? 

I'll have to ask you which feature you are referring to.

I'll try to guess:

FVWM_USERHOME  is needed since  FvwmAnimate, FvwmForm and FvwmDefaults
have to have  some way to  know where to  write the users config file.
Someone on  this  list said  3 fvwm  config  files in the  users  home
directory are 2 too many.

The new form FormFvwmDefaults automates the initial .fvwm2rc creation.

But to be more general, imagine you have a Win**** user who also has a
UNIX workstation on their desk.  This user doesn't know how to operate
any  editor, let  alone vi.  Suppose  you also  thought that this user
would benefit from using a more robust desktop environment.

---

From: Julian Gilbey <[email-masked]>
Date: Thu, 25 Mar 1999 18:15:58 +0000 (GMT)

> What if the user has no .fvwm2rc file?

So you read it without generating an error if it's not found.  The
system.fvwm2rc file must be fully functional without it.

> holding up the current system.fvwm2rc files as a good example of this.

But what happens when Mr. Sys Admin decides to install a new or
modified version of FVWM with files in different places, or with new
options, or with different hardcoded defaults or....  This is why I
hold that the *basic* configuration should be global, in
system.fvwm2rc, with the users able to modify any bits that they wish
to without having to copy the system one and having to keep up with
any important changes.  See my next post with the Debian
system.fvwm2rc as an example.

> has to go in and undo all that stuff from the system rc file!  Bogus.

Easy to undo, again, see my next posting.

> nothing else.  Without a lot of work :).

Of course ;)

   Julian

---

From: Julian Gilbey <[email-masked]>
Date: Thu, 25 Mar 1999 19:13:22 +0000 (GMT)

> could  adopt, since I  don't  want to create   something if it already

The following is a slightly curtailed and simplified version of the
current Debian system.fvwm2rc, with the boring bits removed.  My
comments for this forum are indicated by introducing them with ###.

===========================================================================

# For the benefit of emacs users: -*- shell-script -*-
# Configuration file for FVWM 2.xx originally by Lars Wirzenius
# modifications by Julian Gilbey <[email-masked]>, copyright March 1999
#
#
# This file can be used both as the system.fvwmrc and the per-user ~/.fvwmrc.
# It uses certain `hooks' (files stored in /etc/X11/fvwm or ~/.fvwm) to allow
# the system administrator and user to modify menus, colors, and so on without
# having to change this file.
#
# The defaults that this file sets up follow my own taste.  They attempt to set
# up a nice, easy, comfortable environment for the "ordinary" user.  However,
# using the hooks, it should be possible to change anything.
#
# Please read /usr/doc/fvwm/README.sysrc.gz for more information.
#
# Hopefully, you will never have to modify this file.
#

#
# Section: pre.hook
#
# Use pre.hook for things that need to be done before anything else.
# For example, various paths (IconPath, PixmapPath, ModulePath) might
# be defined here.
#

### If FVWM is changed to automatically look in the ~/.fvwm directory
### for relative filenames, the second command here will be replaced
### by "Read pre.hook Quiet".  Easy, eh?

### Note also that for every hook, we provide both a system and
### personal hook.  This means, for example, that a sysadmin can have
### a form displayed on screen on startup or the like without having
### to edit the distributed system.fvwm2rc itself.

Read /etc/X11/fvwm/pre.hook Quiet
Read .fvwm/pre.hook Quiet

#
# Section: Various global settings
#
# These settings are personal.
# If you need to modify them, do so in post.hook.
#

### post.hook is read after the rest of the file.  The following are
### "sensible" defaults (i.e., I like them!) which are easily modified
### by the user with no effort in their posthook.

#
# DeskTopSize sets the size of the desktop in units of physical screen
# `pages'.  I prefer to use a single desktop with multiple pages,
# but many people like having multiple desktops.  I thinks its confusing.
#

DeskTopSize 3x3

#
# I like to be able to move between pages or desks simply by moving
# the mouse against the screen border.  I find it very useful.  The
# following command enables this behaviour.  To disable it, the
# command EdgeScroll 0 0 could be placed in the post.hook.
#

EdgeScroll 100 100

#
# When moving a window against the edge of the screen, it is
# nice to have a small resistance before the window is moved outside
# the screen.  This makes it easier to line windows against the
# edges.  I have also added some resistance to scrolling at the edges
# of the screen
#

EdgeResistance 250 100

#
# Section: Styles, colors, fonts, and related things
#
# This section defines the looks, behavior, and other attributes of windows.
# These are also quite personal.  Modify them in post.hook.
#

#
# The following sets window colors.  This is highly personal,
# of course, and I (jdg) have changed it to something I like!!  Feel
# free to destroy my choices in your post.hook!!
#

# Put the defaults in a separate decor so decor users can ignore them
DestroyDecor default-decor
AddToDecor default-decor
+ HilightColor Black OrangeRed
+ WindowFont -adobe-helvetica-bold-r-*-*-12-*

# We have five buttons in the default style: on the left, we have iconify
# and close; on the right: maximize horizontally, vertically and fully.

+ ButtonStyle Reset
+ ButtonStyle 1 Vector 4 50x75@1 25x25@1 75x25@1 50x75@0
[...]

### And if you don't like these, and you know what you are doing, the
### single ButtonStyle Reset command allows you to start again.

#
# The following sets the window decorations: the window title, borders,
# and the handles in the corners.
#

# make the default decor the default:
Style "default-style" UseDecor default-decor, Color Black/DarkOrange
Style "*" UseStyle default-style

[Various Style "*" commands elided, and also some Style "Fvwm*"
commands and other more specific ones.]

# Add icons to some common programs
Style "emacs"       Icon gnu-animal.xpm
[...]
Style "*"           Icon default.xbm

### And these are easily modifyable, too.

#
# Section: Init and restart functions
#
# This section defines the functions InitFunction and RestartFunction.
# InitFunction is executed automatically when fvwm first starts.
# RestartFunction is executed automatically when fvwm restarts itself.
# They share a common hook, init-restart.hook, and two specific hooks,
# init.hook and restart.hook.
#
# init-restart.hook should be used for starting fvwm modules, such as the
# button bar.  init-hook should be used to start other applications; they
# should not be started again, when fvwm is restarted, since they don't
# die like fvwm modules do.  restart.hook exists mostly for completeness;
# tell me if you find any use for it.
#
# InitFunction runs the script setup-background, which looks in
# ~/.fvwm to see if the user wants some specific background color or
# image.
#
# The init.hook, init-restart.hook and restart.hook files should
# contain continuation lines, eg:
#   + "I" Exec xterm
#

DestroyFunc InitFunction
AddToFunc InitFunction
+ "I" Exec setup-background

### All setup-background does is to set up the background using xv or
### xsetroot or similar, using an appropriate config file.

Read /etc/X11/fvwm/init.hook Quiet
Read /etc/X11/fvwm/init-restart.hook Quiet
Read .fvwm/init.hook Quiet
Read .fvwm/init-restart.hook Quiet

DestroyFunc RestartFunction
AddToFunc RestartFunction
Read /etc/X11/fvwm/restart.hook Quiet
Read /etc/X11/fvwm/init-restart.hook Quiet
Read .fvwm/restart.hook Quiet
Read .fvwm/init-restart.hook Quiet

### The defaults hook files are usually empty, except
### init-restart.hook starts a pager as explained below.  But if you
### are unhappy, you can always use DestroyFunc {Init,Restart}Function
### in the post.hook.

#
# Section: Menus
#
# This section defines a small menu structure.  The main menu contains
# some typical entries, and uses a hook (main-menu.hook) to allow the
# user to add new entries.  Most of the default entries are submenus,
# which are also defined here.
#

#
# MWM style menus are easier to use and better for Windows refugees.
#

MenuStyle * mwm, Foreground black, Background grey, Greyed white, \
  Font -adobe-helvetica-bold-r-*-*-12-*

#
# Read in system and user menu definitions.
#

# Read system and user menu prefixes
# The title of the main menu will be provided by the menu-methods script
# which creates an AddToMenu /Debian "Main Menu" Title command in
# menudefs.hook.
#

### The /Debian menu is the main menu, with lots of programs listed in
### sensible categories.

AddToMenu /Debian
Read /etc/X11/fvwm/main-menu-pre.hook Quiet
Read .fvwm/main-menu-pre.hook Quiet

### The main-menu-pre.hook will contain things to go before the main
### contents of the main menu.  (Bit obvious, really.)

### This next bit is interesting.  Debian uses an automatic menu
### generation system which works as follows: each package which wants
### to install an item in a menu places the details in a file
### /usr/lib/menu/<package>.  Each windows manager provides a
### configuration file /etc/menu-methods/<wm> which succinctly
### describes how to generate a menu entry from the given
### information.  Then whenever a package which provides a menu file
### or a windows manager is installed or removed, the menu system
### recreates all of the menus.  For example, the first entries of
### menudefs.hook on my system are:
### 
### AddToMenu "/Debian/Apps/Editors" "Editors" Title
### + "&Emacs 20%/usr/share/emacs/20.3/etc/emacs.xbm%" Exec /usr/bin/emacs20
### + "&Textedit" Exec /usr/X11R6/bin/textedit
### + "&Xedit" Exec /usr/bin/X11/xedit
### + "&jed" Exec xterm  -T "jed" -e /usr/bin/jed

# Read the auto-generated menus
Read /etc/X11/fvwm/menudefs.hook Quiet
Read .fvwm/menudefs.hook Quiet

### And after the system generated stuff:

# Add in user additions
Read /etc/X11/fvwm/main-menu.hook Quiet
Read .fvwm/main-menu.hook Quiet

### Of course, if you want your own menus, either ignore /Debian
### completely with your rebound keys/mouse buttons, or use the
### DestroyMenu function.

# Tack a quit entry on to the end; this version uses a submenu, but it
# is easy to use a pop-up window instead to ask the user to confirm,
# MWM-style, using FvwmForm.
AddToMenu /Debian
+ "Exit Fvwm"  Popup Quit-Verify

#
# The Window-Ops menu is for manipulating windows.  It is invoked either
# from the main menu, or directly from the root window.
#

DestroyMenu Window-Ops
AddToMenu Window-Ops
+ "Window Ops"               Title
+ [...]

#
# The Quit-Verify menu checks that the user really wants to exit.
#

DestroyMenu Quit-Verify
AddToMenu Quit-Verify
+ "Restart Fvwm"   Restart fvwm2
+ ""               Nop
+ "Really quit"    Quit

#
# Section: Mouse bindings
#
# This section defines the mouse bindings, that is, all the things that
# can be done with the mouse.
#

#
# Each button gives a different menu from the background (root window).
#

Mouse 1   R  A  Menu /Debian
Mouse 2   R  A  Menu Window-Ops
Mouse 3   R  A  WindowList

[Lots more mouse bindings elided]

#
# Section: Key bindings
#
# This section binds some actions to keys.  The bindings have been inspired
# by MWM, Windows, and nightmares.  Everything that these key bindings do,
# can be done without them.  Therefore they should not be too much of a
# burden on new users, but it definitely _can_ be confusing to press a
# key by accident and have it do something completely unexpected.
#

Key Tab   A    M    Next [CurrentPage !iconic] focus-and-raise
Key Tab   A    MS   Prev [CurrentPage !iconic] focus-and-raise
[...]

#
# Section: Functions
#
# This section defines various functions.  Not all of these are used by
# the default bindings, but they can be useful for a user who wants to
# customize things.
#
#
# The following functions operate on a window or menu.  The
# names are systematic: foo means "do foo"; foo-or-bar means
# "do foo, if mouse is moving, bar if click"; and foo-or-bar-or-baz
# adds "baz, if double-clicked".
#

DestroyFunc move-or-winmenu-or-deiconify
AddToFunc   move-or-winmenu-or-deiconify
+ "M" Move
+ "C" Popup Window-Ops
+ "D" Iconify

[lots more functions elided]

# Configure a FvwmButtons module for the modules menu, but make sure
# user can easily override it with their own - so name it DebianFvwmButtons.
# To use this config, you need to invoke it as:
#   "Module FvwmButtons DebianFvwmButtons"
#
*DebianFvwmButtonsFore White
*DebianFvwmButtonsBack DarkSlateGrey
*DebianFvwmButtonsGeometry 430x100-0-0
*DebianFvwmButtonsRows 1
*DebianFvwmButtons(Title Help, Icon xman.xpm, Action 'Exec "Xman" xman &')
*DebianFvwmButtons(Title xterm, Icon xterm.xpm, Action 'Exec "XTerm" xterm &')
*DebianFvwmButtons(Title emacs, Icon gnu-animal.xpm, Action 'Exec "Emacs" emacs &')
*DebianFvwmButtons(2x1, Swallow(UseOld,NoKill) "FvwmPager")

### Note that DebianFvwmButtons must be invoked from one of the hooks
### or by using something like FvwmCommand; it is not invoked by
### default, but provided to make the user's life a little easier by
### providing a usable default.

#
# Configure the FvwmPager module
#

### ... which you are, of course, at liberty to modify.

*FvwmPagerBack SlateGrey
*FvwmPagerFore Black
*FvwmPagerFont none
*FvwmPagerHilight SlateBlue4
*FvwmPagerGeometry -0-0
*FvwmPagerSmallFont -*-times-medium-r-*-*-*-80-*-*-*-*-*-*
*FvwmPagerDeskTopScale 32

# We start the pager in the InitFunction and RestartFunction, so that the

### that is, the default system init-restart.hook contains the line
### + "I" Module FvwmPager 0 0

# user has control over whether it starts or not.  We do this by placing
# it in the system init-restart.hook, so that either the administrator
# can remove it or infividual users can kill it or set it up differently
# by placing something like the following in their personal
# init-restart.hook:
#    + "I" Wait FvwmPager
#    + "I" KillModule FvwmPager
#    + "I" Module FvwmPager 0 3

### OK, this is not a one-line solution for the DIY enthusiast, but
### means that there is a usable default to begin with which is
### relatively easily modifiable.

#
# Section: post.hook
#
# Use post.hook to force things that may have been changed earlier, for
# example, key bindings.
#

Read /etc/X11/fvwm/post.hook Quiet
Read .fvwm/post.hook Quiet

==========================================================================

This is the model I have been using until now, and provides a very
nice balance of partial configurability and decent, usable defaults.

   Julian

---

From: Pete Forman <[email-masked]>
Date: Fri, 26 Mar 1999 08:07:39 GMT

> comments for this forum are indicated by introducing them with ###.

A small point of marginal relevance to this list is that XEmacs has a
window manager mode, winmgr-mode.  This is automatically invoked when
working on .fvwm2rc or similar name.  The initial line may cause
shell-script mode to be used instead.  That is probably the right
thing to do for Emacs, so feel free to ignore this comment if your
users use both Emacs and XEmacs.
-- 
Pete Forman
Western Geophysical
[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]