Subject: New default config file ~/.fvwm/config

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 4 Feb 2004 01:26:41 +0000

I already started this topic several times in the past, but it seems
noone else worries about this. I worry, so I will implement this soon.
In short, ".fvwm2rc" name has 3 small problems as explained in todo-2.6.

I suggested either ~/.fvwm/main or ~/.fvwm/config variants in the past.
The second one seems to be the most intuitive. Also ~/.*/main does not
return anything for me, and ~/.*/config returns 12 application config
files in my home directory.

Currently fvwm searches for the starting config file in 5 places, I will
add 2 more places, i.e. $FVWM_USERDIR/config and $FVWM_DATADIR/config.
Some places (like ~/.fvwm2rc in $HOME) should be removed, either before
or after 2.6.0. Of course, ~/.fvwm/.fvwm2rc should stay for some years.

Another thing I will do later is to go throw all zillions places
containing the string ".fvwm2rc" and replace it with "~/.fvwm/config".
This way we will be completely free from "2" in our file names.

Note that ~/.fvwm/config is designed to be the final fvwm config file.
A user may already dispatch it if he really wants, like:

  Test (Version 2.5.*) Read config-2.5
  Test (Version 2.6.*) Read config-2.6

Regards,
Mikhael.
--
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, 4 Feb 2004 09:42:57 +0100

> In short, ".fvwm2rc" name has 3 small problems as explained in todo-2.6.

In my eyes, it might be better to do this with 3.0 in order to do
all the disrupting changes in one release.  Users get the feeling
we are constantly breaking compatibility if we do such changes in
small doses.  Other than that, I have no strong opinion about the
issue.

> files in my home directory.

~/.fvwm/config is better

> or after 2.6.0.

After - namely for 3.0 (i.e. 2.6.1 ?).

> Of course, ~/.fvwm/.fvwm2rc should stay for some years.

Dito.  It shouldn't be called .fvwm2rc once 3.0 is on the way.

> containing the string ".fvwm2rc" and replace it with "~/.fvwm/config".

I'm not sure this is wise at the moment.  Too many people are reading
documentation that comes from a different version.  They may be
utterly confused if they miss that fact.  As ugly as it may be, I
suggest to write both, .fvwm2rc and .fvwm/config, until 3.0.

>   Test (Version 2.6.*) Read config-2.6

By the way, this should definitely allow things like

  Test (Version [>|<|>=|<=] 2.5.7) ...

Ciao

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 4 Feb 2004 13:49:17 +0000

> small doses.  Other than that, I have no strong opinion about the

My argument is that I don't think we will have 3.0 in less than three
years, and it would be nice to have the clean solution now. As described,
it does not break compatibility, just prepares a user in advance.
As for the future, it is possible that there will be 2.8, or maybe 3.0
will be mostly backward compatible (like 2.6 is), it can't be predicted.

>   Test (Version [>|<|>=|<=] 2.5.7) ...

This may be added.

A bigger problem is that currently $[cond.rc]  (should it be renamed?)
is always Match outside of functions, so TestRc (!Match) never works.
This is a bit problematic for dispatchers, they may want to have "else".

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 4 Feb 2004 15:03:49 +0100

On Wed, Feb 04, 2004 at 01:49:17PM +0000, Mikhael Goikhman wrote:
> years, and it would be nice to have the clean solution now.

I think it could be done in 2.7.1 as well.  In any case, as long
as it's optional in the 2.x series, I have no problem with the
change.

> As described,

Due to the several concurrent sources of input (user interaction,
modules, X events and the Schedule queue), a lot of scripting does
not work when done outside functions.  FvwmIconMan has that
problem in its button action syntax.  Module input in general is
problematic.  The Repeat and "+" commands can be dangerous too,
probably other commands that I missed too.  But I don't know what
we could possibly do about it.

Ciao

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 4 Feb 2004 14:55:33 +0000

> we could possibly do about it.

I suggested a solution to all these problems some time ago.

Currently we have some globals (like last_return_code, last_added_item).
These should be local to every module pipe. This way all commands from
one FvwmConsole do not conflict with commands from another FvwmConsole.

The initial start config commands, X event commands and Schedule commands
all should have their own allocation of this inter-command state data and
should never affect the state of each other and of module pipes.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 4 Feb 2004 18:06:21 +0100

On Wed, Feb 04, 2004 at 02:55:33PM +0000, Mikhael Goikhman wrote:
> all should have their own allocation of this inter-command state data

Handling X events is easy since they never refer to each other.

> and should never affect the state of each other and of module
> pipes.

But still, at the moment there is no way to reliably issue
sequences of commands with Schedule.  I've been thinking about
some kind of inline function definition for a while, e.g. instead
of

  destroyfunc foo
  addtofunc foo
  + i do this
  + i do that

it might look like this:

  inline "do this" "do that" ...

Fvwm would translate that automatically into an anonymous function
and execute it.  Passing arguments and quoting will be problematic,
though.

Ciao

Dominik ^_^  ^_^

---

From: parv <[email-masked]>
Date: Wed, 4 Feb 2004 17:26:56 -0500

in message <[email-masked]>,
wrote Mikhael Goikhman thusly...
>
> I suggested either ~/.fvwm/main or ~/.fvwm/config variants in the
> past.  The second one seems to be the most intuitive.
...
> Currently fvwm searches for the starting config file in 5 places,
> I will add 2 more places, i.e. $FVWM_USERDIR/config and
> $FVWM_DATADIR/config.  Some places (like ~/.fvwm2rc in $HOME)
> should be removed, either before or after 2.6.0. Of course,
> ~/.fvwm/.fvwm2rc should stay for some years.

I hope there still be a way to specify the path to the configuration
file like the way -f option currently allows (fvwm 2.5.8) to
specify.  Otherwise, i am indifferent about the issue.

  - Parv

--