Subject: FVWM: .fvwm2rc syntax guide?

From: Len Philpot <[email-masked]>
Date: Fri, 23 Aug 2002 22:01:27 -0500

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 and the few pointers I do find in the man pages are scattered and
terse, to say the least.

Sorry if I sound frustrated, but I am...

I've just spent 30 minutes or more with one MenuStyle line trying to get
it to work (without success).  Despite close to an hour's work, I've
been unable to get FvwmTaskBar to appear at the bottom of the screen
(despite following the examples from the man page). I can change the
border widths and nothing ever happens.  I've used the recommended
geometry, but it always appears at the top of the screen. I'm light
years away from doing anything useful with it, but at this rate I'll
never get there. I'm having the do *EVERYTHIHG* by trial and error,
since the man page is so vague (or maybe I'm just stupid...?).

I'm rapidly reaching my frustration threshold before moving on to
something else.

There has to be somewhere a definition of exactly what is and isn't
allowed configuration-wise, where specific entries need to go,
recommended order, syntax restrictions, case-sensitivity, etc., etc.

If anyone can help, I'd appreciate it. I really like the speed and small
size of fvwm, but the appalling lack of documentation is about to
convince me to look elsewhere...

Thanks.

-- 
+-----------------------------------------------------+
|  Len Philpot       ><>         http://philpot.org/  |
|  [email-masked]     [email-masked] (alt)  |
+-----------------------------------------------------+
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 24 Aug 2002 11:10:13 +0200

On Fri, 23 Aug 2002 22:01:27 -0500
Len Philpot <[email-masked]> wrote:

[...]

> since the man page is so vague (or maybe I'm just stupid...?).

Hi,
I just wanted to add that fvwm2 is a great window manager - but I agree
that the man page is hard to read and understand!

So here is a little suggestion to improve the man page: Insert a section
(at the beginning) which deals with the basic configuration faqs - and
show examples right there. Most important: Let this section be organized
by *the point of view of a beginner* who just wants to change color of
background, change the root menu, change the window styles. If he passed
that he will have enough starting enegery to go through the rest of the
man page. ;-)

(I hope the one who wrote the man page is not insalted ... ;-)

Bye
 Felix

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 24 Aug 2002 10:22:32 +0000

> file and the few pointers I do find in the man pages are scattered and

The only authoritative guide to the proper syntax is man pages. You may
just start with an empty file and put any commands described in the man
page in any order according to your needs. Use functions for efficiency.
Usually you need at least:

  # StartFunction to start modules, InitFunction to start apps
  # mouse and key bindings
  # color definitions, I suggest to use colorsets
  # window decorations including border, buttons, title bar
  # menu definitions
  # module configurations
  # global and window specific styles

If you want examples, I can suggest is to take a look at the themes of
fvwm-themes. For example, here is the content of the default theme:

    background
  + bindings
  + buttons
  + colors
  + cursors
    fonts
  + functions
  + functions-appbind
  + globalfeel
  + globallook
  + menus
  + menus-programs
  + menustyle
  + modules/
    settings/
    sound
    startup
  + styles
  + windowlook

Most of these components are plain fvwmrc configs, but not all.
There are several special functions that make the whole thing
configurable and efficient that you may ignore when creating .fvwm2rc.
I marked by plus the components that you may just learn from.

If you like the concept of dividing the entire configuration into
replaceable components, you may customize fvwm-themes by creating your own
theme (directory) with several components (files), but read its FAQ first.

> since the man page is so vague (or maybe I'm just stupid...?).

Do the following. Open FvwmConsole (start it in StartFunction or bind to
a menu). Then type these commands in FvwmConsole:

  *FvwmTaskBar: Geometry +0-0
  FvwmTaskBar

Does it still appear on the top? Is it possible you change another
.fvwm2rc? You should edit ~/.fvwm/.fvwm2rc.

> convince me to look elsewhere...

The man pages are complete, although may contain small glitches that are
constantly fixed. Please try to narrow your problems with documentation.
For each problem start a new thread here and specify what you did, what
you got and what you want/expect to get. Provide all relevent details.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sat, 24 Aug 2002 10:14:47 -0400

Len Philpot <[email-masked]> writes:
> file

Please point out the conflicts so that they can be repaired.

> Sorry if I sound frustrated, but I am...
...
> I can change the border widths and nothing ever happens.

There are 2 borderwidths, for windows and menus.

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:

              With  the  NoHandles style, the window does not get
              the handles in the window corners that are commonly
              used  to resize it.  With NoHandles, the width from
              the BorderWidth style is used.  By default,  or  if
              Handles  is  is  specified, the width from the Han
              dleWidth style is used.

So, if you have

 Style * NoHandles

Then this works:

 Style * BorderWidth 10

Otherwise, use this:

 Style * HandleWidth 10

> convince me to look elsewhere...

Fvwm may be speedy and small, but the amount of configuration possible
is massive.  Hence the extremly large man page, and difficulty getting
started.

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: parv <[email-masked]>
Date: Sat, 24 Aug 2002 17:39:10 -0400

in message <[email-masked]>,
wrote [email-masked] thusly...
>
> So here is a little suggestion to improve the man page: Insert a
> section (at the beginning) which deals with the basic
> configuration faqs - and show examples right there.

man pages are there for reference.  their function is not to be a
collection of FAQ's, tutorials & what not.  they can, however, point
to other resources which may provide the help that a beginner may
need.

the default F1 key binding (for fvwm help) could/should point to
such tutorials & FAQ's instead of a man page then.

let's not spam the man page please.

speaking of which, is there any plan in near future to remove
"GlobalOpts ... -> Style" pointers?

  - parv

--

---

From: Rainer Koehler <[email-masked]>
Date: Sat, 24 Aug 2002 19:15:05 -0700

> that he will have enough starting enegery to go through the rest of the

So, why don't you go ahead and write something like that?

With this ongoing discussion about the manpage, I'd like to add my two
cents (US or Euro - I don't know).  I've been using fvwm longer than I
can remember.  However, I can remember the times when it was
maintained by Rob Nation, and I think there's still a tape with my
config-file for fvwm 1.xy, although I doubt that I can find a drive to
read it.

The thing I like most about fvwm is it nearly infinite flexibility and
configurability.  That comes with a price, the documentation is only
for someone who is willing to read a whole reference manual before he
starts using the program.  But even the best documentation would be
long (probably too long for newbies) and difficult to understand
because for many things you have to understand the whole picture
(which sometimes includes more than fvwm).

And frankly, I don't want the fvwm developers to write documentation
for beginning.  I want them to fix old bugs and add new features so I
can get more out of it.  That works pretty well so far.  If fvwm came
with a graphical configuration tool, I could as well use Gnome, KDE,
or M$-Windows.

Also, I don't think the fvwm developers would be very good at writing
a tutorial for beginners.  You have to remember how it was when you
were a newby to write something a newby can understand.

It would probably be best if someone who wrote or modified his first
fvwm2rc not too long ago would write a few paragraphs about what he
wanted and how he achieved it.  I'm sure the developers would be
willing to comment on it and give advice if there are better ways to
achieve the desired behavior.  But it's *YOU*, the newbies out there
who know what the confusing things are, not the fvwm developers!

Fvwm and its documentation are open source, if there's something you
don't like, fix it.  If you are able to edit your fvwm2rc, you should
be able to write a little text about it, you don't need a degree in
computer science for that.

Thank you for your attention, I go back to lurking now.
Rainer

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 25 Aug 2002 11:12:38 +0200

> to other resources which may provide the help that a beginner may

Exactly.  So we're back to the issue that we need a tutorial.

> such tutorials & FAQ's instead of a man page then.

Or maybe not.  The F1 key is overloaded already by the various
help systems.

> "GlobalOpts ... -> Style" pointers?

It may not be in the near future.  But the GlobalOpts command
*will* be removed in 3.0.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 25 Aug 2002 15:40:48 +0200

On Sat, 24 Aug 2002 19:15:05 -0700
Rainer Koehler <[email-masked]> wrote:

> > section(at the beginning) which deals with the basic configuration
> > faqs - and show examples right there. Most important: Let this
> > section be organized by *the point of view of a beginner* who just
> > wants to change color of background, change the root menu, change
> > the window styles. If he passed that he will have enough starting
> > enegery to go through the rest of the man page. ;-)
> 

[...]

> a tutorial for beginners.

Concidering myself a newbie I'd like to do that. The only problem is: a
newbie knows the problems - but can't provide the solutions.

I don't think you'll spam the man page if you insert a short section for
the main issues beginners have. And, my favorite way to do it is nearly
already done: Look at man FvwmIconMan, "Configuration Options Reference
Chart". Add one single column to it with an example command and there
you go.

Look, isn't fvwm2 worth it to forget maybe tine a little bit about the
guide lines of man pages and follow the wishes of many beginners to
fvwm2 - since they'll all start typing m-a-n instead of querying goole
for some tutorial?

Please excuse my passion - it's just the passion for fvwm2.

'bye
 Felix

---

From: Len Philpot <[email-masked]>
Date: Sun, 25 Aug 2002 16:18:42 -0500

> computer science for that.

Agreed - Except that it's a bit difficult to accurately document
something in terms someone else can understand when the "documetor"
doesn't understand it. For example, I've seen the following examples for
FvwmTaskBar :

>From the fvwm webpage :

Style "FvwmTaskBar" NoTitle,BorderWidth 4, HandleWidth 4,Sticky,
StaysOnTop,WindowSkipList,CirculateSkip 
#------------------------------------ taskbar
*FvwmTaskBar: Back #c3c3c3
*FvwmTaskBar: Fore black
*FvwmTaskBar: TipsBack bisque
*FvwmTaskBar: TipsFore black
*FvwmTaskBar: Geometry +0-0
*FvwmTaskBar: Font -adobe-helvetica-medium-r-*-*-14-*-*-*-*-*-*-*
*FvwmTaskBar: SelFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-*
*FvwmTaskBar: StatusFont fixed

>From the FvwmTaskBar 2.6  man page on my system :

Style "FvwmTaskBar" NoTitle,BorderWidth 4, HandleWidth 4,Sticky,
StaysOnTop,WindowSkipList,CirculateSkip

#------------------------------------ taskbar
*FvwmTaskBarBack #c3c3c3
*FvwmTaskBarFore black
*FvwmTaskBarTipsBack bisque
*FvwmTaskBarTipsFore black
*FvwmTaskBarGeometry +0-1
*FvwmTaskBarFont -adobe-helvetica-medium-r-*-*-14-*-*-*-*-*-*-*
*FvwmTaskBarSelFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-*
*FvwmTaskBarStatusFont fixed

I am in no way singling out FvwmTaskBar - I just happened to be working
with it lately. The second example works, the first doesn't (as far as I
can tell). This is typical of what I'm apparently misunderstanding. It
appears that fvwm plays very loose and fast with the config file in
terms of syntax? Or am I just missing something? It appears that there's
always more than one way to do anything, which I guess has its merits,
but is almost always initially more confusing than a tightly controlled
syntax. For example, do all of the parts of a function or menu
definition need to be in one place (immediately under the AddToFunc or
AddToMenu), or can they be spread around. If the latter, what's the
advantage? It seems like you'd want them all grouped together anyway,
just organizationally. I tend to look on config files in general much
like source code - Make them modular, organized and as easy to read as
possible.

I've seen a couple of replies to my original post that I've yet to read
carefully and digest, so I'll not waste bandwidth here asking questions
they may answer.

However, I do have one concerning FvwmTaskBar (no, make that two) :

1. With BorderWidth and HandleWidth set to 1 or 0, the taskbar doesn't
occupy the full width of the screen. Is there a way to force this?

2. When I configure a Popup StartMenu, is there a way to accurately
control where it appears on screen, in regard to the Start button? If I
understood MenuStyle a bit better, maybe the answer is there
(PopupOffset, or whatever it's called)...?

OK - One more (general) question :

Is there a way to globally turn off mouse pointer warping so that it
never warps to a menu, window, whatever? That's one behavior I _really_
would like to get rid of, particularly on popup menus.

Thanks.

---

From: Len Philpot <[email-masked]>
Date: Sun, 25 Aug 2002 16:38:44 -0500

> 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).

> 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.

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. 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? Is there a definite order to options? Is it
case-sensitive?

> is massive.  Hence the extremly large man page, and difficulty getting

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.
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.

Just my $0.02.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 25 Aug 2002 22:20:47 +0000

> *FvwmTaskBarStatusFont fixed

There is no such version 2.6. The man pages on the web are for fvwm 2.4.x.
You seem to use 2.2.x which is very old. Of course, you should contact
the man pages matching your version. In 2.4.x both syntaxes should work,
but the one in the man page is preferable. I think +0-0 is a more correct
geometry than +0-1, but 2.2.x may have some bugs about this.

> occupy the full width of the screen. Is there a way to force this?

Yes, use the latest stable or unstable versions.

> (PopupOffset, or whatever it's called)...?

Yes, you may do this accurately in 2.5.1+, scan NEWS file.

In 2.4.x, you may do this too using Rectangle or Mouse hint (there are
examples in fvwm-themes), but not as accurately as in 2.5.x.

> would like to get rid of, particularly on popup menus.

Globally, no.

If you bind a menu to a key, it altomatically selects the first selectable
menu item (and thus warps the pointer), but after working with such menu
the original pointer position is restored. It is good when you work with
keyboard only. If you bind a menu to a mouse it does not warp.

For example, in the following if you press Ctrl-Shift-F10 it warps, but
Ctrl-Shift-Mouse1 does not:

  Key F10 A CS Menu MenuFvwmRoot Rectangle 1x1+10+10 0 0
  Mouse 1 R CS Menu MenuFvwmRoot Rectangle 1x1+10+10 0 0

What exactly annoys you about menus and windows? Provide configurations.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 25 Aug 2002 23:48:38 +0000

> 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. :)

> 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.

> 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
> 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.

> 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?

> 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.

---

From: Rainer Koehler <[email-masked]>
Date: Sun, 25 Aug 2002 16:50:02 -0700

> newbie knows the problems - but can't provide the solutions.

You can ask the questions here and collect the answers.  I'm always
surprised how patiently the developers answer the same questions over
and over again (except that "after a while, all my keybindings stop
working" :-)

Questions with concrete wishes are much easier to answer than
"I fiddled with the config file for hours and it didn't work".

> Chart". Add one single column to it with an example command and there

Hmm, I think the same table for fvwm itself would be sevaral pages
long, but I agree, it would be a good idea to have something like
that.

> fvwm2 - since they'll all start typing m-a-n instead of querying goole

Well, I consider someone who knows about man and is willing to use it
no longer a real newbie :-)

Another post here raised suspicion that someone read the manpage on
the web and tried to apply it to the fvwm on his system (without
success because he uses a different version).  So maybe it would be
better to write it in HTML.  For many, it might be easier to write
something in HTML than to write a manpage.

But the format doesnt really matter, what's missing is the content!
I would vote for splitting the manpage into some kind of introduction
or a tutorial and a reference manual, but so far, only the reference
part exists.

> Please excuse my passion - it's just the passion for fvwm2.

I think we share that passion, that's why I get a bit angry when
someone complains about the manpage without giving the impression that
he is willing to do something about it.

Cheers,
Rainer

---

From: Dan Espen <[email-masked]>
Date: Sun, 25 Aug 2002 20:29:50 -0400

Len Philpot <[email-masked]> writes:
> notations, etc. Is this correct?

No, I don't think so.
There's only 1 shorthand in fvwm, I can think of and thats "+"
which "continues" "AddToxxx" commands.

You can either do this:

  AddToMenu Utilities Utilities Title
   + Xterm           Exec  exec xterm -e tcsh
   + Rxvt            Exec  exec rxvt

or this

  AddToMenu Utilities Utilities Title
  AddToMenu Utilities Xterm           Exec  exec xterm -e tcsh
  AddToMenu Utilities Rxvt            Exec  exec rxvt

> All styles? I guess not, since that doesn't make sense, given the

Why wouldn't

make sense?  It changes the borderwidth of all menus to 10.

> and there.

Older versions of fvwm used the quotes in examples,
they were never necessary, and they've
been banished from the documentation and samples for a while now.

> such as myself could see what does and doesn't change.

Are you aware that you can start fvwm with no config file at all,
press F1 or any mouse button on the root window and fvwm will
offer to create a few different configurations for you?

---

From: Len Philpot <[email-masked]>
Date: Mon, 26 Aug 2002 21:26:56 -0500

> examples in fvwm-themes), but not as accurately as in 2.5.x.

I'm using FvwmTaskBar, with no RootMenu configured, but rather all the
same entries on the StartMenu. It pops up just fine when I click the
task bar button, but the position is relative to the mouse pointer, not
to the task bar. That's what I'm trying to achieve. I'm currently
running 2.4.6, BTW (latest RPM for RedHat 7.x I could locate in a quick
search). Here's what I've tried to pin down the location:

AddToMenu StartMenu Root x y SelectInPlace

...where x and y are various offsets. I would expect x to be 0 and y to
basically be height_of_root_window - height_of_menu - height_of_taskbar.
In this intance, referencing the lower left corner of the menu would
have been more convenient and less prone to change, although menu's
typically _do_ drop down, so I see the value in the upperleft reference
point.  Trouble is, it doesn't seem to make any difference at all what I
put there - Nothing ever changes. My MenuStyle is :

MenuStyle * Foreground black, Background grey70, Greyed grey90,\
 HilightBack grey60, ActiveFore black, Hilight3DThickness -1, \
 font -adobe-helvetica-medium-r-*-*-12-*-*-*-*-*-*-*, Animation,\
 PopupDelay 55, PopdownDelay 5, TitleWarpOff, SeparatorsLong,\
 TrianglesRelief, PopupOffset 0 95

...with the exception that it's actually all on one line. It works as
expected, but is something there interfering?
 
> What exactly annoys you about menus and windows? Provide configurations.

It's just that I prefer the mouse pointer to stay where it is when I
click it. In general, I'm not a big fan of anything in the UI
"responding" or taking any kind of action without an explicit
instruction on the part of the user. I'd rather not even have the menu
selection move with the mouse without the button being down, given a
choice, and I don't care for "highlighting" icons that change as you
mouseover them (so popular in Windows, Gnome, KDE, etc.), but that's
just my personal GUI preferences. I like intefaces that are totally
static until acted upon by the user. Once again, just my preference.
Even under Windows, I don't turn on the option to jump to the active
control. With those sort of things active, I tend to spend more time
looking for the mouse pointer. The way I have it now, I have no warping
happening, at least none I've noticed, so I'm happy with that.

Let me clarify something - I may have inadvertently come across as
critical of fvwm and the way things are done. That was not intentional,
but rather just the product of frustration (indeed, I even stated such
in one post). I usually never write when in such a state, as I always
regret it later. I'll state again: I like what I'm learning of fvwm and
I'm appreciative of the help; it's just that the learning process is
somewhat painful at times (at least, it smarts here and there...).

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 27 Aug 2002 11:24:14 +0200

> AddToMenu StartMenu Root x y SelectInPlace

You are adding the position hint to the wrong command.  It only
works with the "Menu" and "Popup" commands.  This is because it's
a parameter of a specific menu invocation, not of the menu as a
whole.  Try this instead:

  *FvwmTaskBarStartMenu RootMenu root +0p o100-25p SelectInPlace

FvwmTaskBar passes the whole string with "Menu" prepended to fvwm.
It's really not the most intuitive syntax I could make up.

> put there - Nothing ever changes.

See above.

> My MenuStyle is :
> ...with the exception that it's actually all on one line.

You can split it into multiple lines for readability as long as
the mwm or fvwm menu style appears as the first item of the list
(as both override most settings):

  MenuStyle * Foreground black, Background grey70, Greyed grey90
  MenuStyle * HilightBack grey60, ActiveFore black
  ...

> It works as expected, but is something there interfering?
>  

That's mostly a relic of the "fvwm" menu style.  I never
understood why it had to be so annoying, but we never changed it
fpr backward compatibility.  The first menu style everybody may
want to use is

  MenuStyle * mwm

which corrects most of the funny behaviour.

> somewhat painful at times (at least, it smarts here and there...).

You're welcome.  I know the documentation isn't good for
beginners.  As someone else pointed out, being a developer
disqualifies me for writing a tutorial.  That again brings us back
to the issue that we need a volunteer to write and maintain such a
guide.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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 [email-masked].
To report problems, send mail to [email-masked].