Re: FVWM: .fvwm2rc syntax guide?

From: Mikhael Goikhman <migo_at_homemail.com>
Date: Sun, 25 Aug 2002 23:48:38 +0000

On 25 Aug 2002 16:38:44 -0500, Len Philpot wrote:
>
> On Sat, Aug 24, 2002 at 10:14:47AM -0400, Dan Espen wrote:
> > Len Philpot <len_at_philpot.org> writes:
> > > Is there a concise, authoritative guide to the proper syntax,
> > > organization and such of .fvwm2rc contents somewhere? What I see in the
> > > fvwm man page often conflicts with what's in the sample system.fvwm2rc
> > > file
> >
> > Please point out the conflicts so that they can be repaired.
>
> I've done so on FvwmTaskBar, at least to a small degree, in another
> post. At this point, I'm not sure how much is inconsistency and how much
> is just misunderstanding on my part. For example, the MenuStyle line
> in the system.fvwm2rc that was installed on my system was in the old
> style, according to the man page. I was trying to basically get the WIN
> look, with a couple of things changed. However, I couldn't figure out
> the precedence, so my changes never took effect. Usually, the menu would
> revert back to the default look (I presume).

I hope when you install the version that corresponds to the man pages, the
man pages may just magically start to work. At least I hope so. :)

> > For menus, this works:
> >
> > MenuStyle * BorderWidth 10
> >
> > I suspect you are having problems with the borders on windows.
> > Perhaps you missed this in the man page:
>
> Right now, I think my issues are more with an understanding of the
> fundamental syntax of the config file, not the actual values in it. It's
> looking more and more to me that conceptually, the config file is a bit
> like Perl in that there are implied values, multiple syntaxes, shorthand
> notations, etc. Is this correct? If so, that's something that's always
> given me the willies, personally. I tend to like a specified way of
> doing something, but that's my preference. Once I understand this, I'm
> sure I'll settle on one way. Until then, it's a bit confusing.

I would not say the syntax is fundamentally weak, i.e. supports all kinds
of errors or different ways of doing the same. In some places (usually
some exotic modules) the syntax is very unforgivable without enough error
messages. There is also a lot of backward compatibility stuff, this is
probably why you think there are several ways of doing the same.

> For example, in your MenuStyle example above, what's the asterisk for?
> All styles? I guess not, since that doesn't make sense, given the
> context.

I think the man page entry for MenuStyle (and other commands in the
"COMMANDS FOR MENUS" section) explains what asterisk means.

> Should it be in quotes: "*"? I've seen it that way as well here
> and there. I understand about quoting values containing spaces, but how
> about without them?

There are some places (usually modules, again) when you should strictly
write it without quotes or, instead, with quotes depending on what the man
page says. But for the core fvwm, the rule is usually simple. There is a
concept of word (or token). This is either something without spaces and
other delimiters or something that is in quotes (there are 3 pairs of
quotes). So, "*" and * are the same, but " *" and * are not, because
spaces are only significal when in quotes.

> Is there a definite order to options?

Do you mean the order of commands or the order of options in a command?

Almost in all cases (unless the man pages says otherwise) if a command has
multiple optional options, their order does not matter. Of course, the
order of mandatory parameters does matter. Example: the order of options
in commands Style, MenuStyle (forget the obsolete syntax of MenuStyle),
ButtonStyle, TitleStyle, WindowList, BusyCursor does not matter. If
some option in these commands is not specified there is a good default.

Some commands depend on the result of other commands, in this case the
order of commands matters. Otherwise it does not matter. Simple, no? :-)

> Is it case-sensitive?

It is preferable to stick to the case used in the man pages to be sure.
But a lot of places are case-insensitive for convenience.

> > Fvwm may be speedy and small, but the amount of configuration possible
> > is massive. Hence the extremly large man page, and difficulty getting
> > started.
>
> What I'm thinking of would be along the lines of what we've all seen in
> programming tutorials : skeleton diagrams with placeholders showing how
> everything is specified, in what order, what case, with what
> punctuation, what's mutually exclusive, what's dependent on each other,
> etc., etc. Then some simple examples that build on each other, instead
> of a massive .fvwm2rc that can walk and talk and do the jitterbug. Also,
> make the examples dovetail with FAQs on how and what can be done.

Unfortunately there is a problem with who will do this.
Do you want to help with this?

> Someone else mentioned what I think is a very good idea: Supply a few
> different config file samples that contain the same "content", but with
> a differnt look and feel (native, Win95, CDE, etc.). That way, a newbie
> such as myself could see what does and doesn't change.

But if I say you that this already exists and not only this, the
configuration is divided into logical parts, so you should compare only
these parts, not the full fvwm2rc, will this change anything?

Face it. Users are lazy (me included). If they can't read the man pages,
all other tricks suggested above will not help. Such users should just ask
on this list and they will be answered with pleasure. :)

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Sun Aug 25 2002 - 18:49:35 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:53 BST