> 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 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 Fries...tfries_at_umr.edu
http://www.cs.umr.edu/~tfries
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Sep 25 1995 - 09:13:43 BST