Subject: FVWM: How do I start modules automatically?

From: Johann Oskarsson <[email-masked]>
Date: Wed, 7 Aug 2002 21:21:55 +0500 (GMT-5)

Hello, I'm sort of new to fvwm and don't know anything about anything.
Thanks, guys (if you who make it are reading this).

What I want to know is how I make the AutoRaise module start automatically
when I log in to X.

Thanks for whatever help I can get,

Johann

--
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: Jan Johansson <[email-masked]>
Date: Wed, 7 Aug 2002 23:33:24 +0200

>Thanks for whatever help I can get,

man fvwm or man fvwm2

Look for InitFunction or StartFunction.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 8 Aug 2002 02:20:00 +0200

> What I want to know is how I make the AutoRaise module start automatically

Place the lines

  AddToFunc StartFunction
  + I FvwmAuto 500

in you $HOME/.fvwm2rc file.  Although its very big, the man page
is a good source of fvwm related information, but don't hesitate
to ask questions on the mailing list - that's its main purpose.

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: Len Philpot <[email-masked]>
Date: Thu, 8 Aug 2002 21:07:02 -0500

> to ask questions on the mailing list - that's its main purpose.

While I agree the fvwm man page is extensive and a good source of info,
it's (unfortunately) hardly a tutorial. Of course, man pages aren't
generally meant to be tutorials, but it would certainly be nice to have
one somewhere. I saw one other post on the list of a small tutorial and
have read that, but that's apparently about it. I get the feeling I
won't understand much of anything until some magic moment after reading
enough when it all comes together at once...

I've seen many sample .fvwm2rc's that can walk and talk and create an
amazing desktop, but trying to learn the fundamentals of fvwm from them
is a bit like trying to learn to drive with your first car being a top
fuel dragster... :-)

I'm VERY early on in my fvwm career and am still flailing about more
than a bit, so a more stepwise approach would be great if anyone knows
of one out there. In fact, it was the 'blessing' of a 233mHz laptop with
only 64MB that pushed me in the direction of fvwm. KDE is slow on that
machine and Gnome is out of the question. Of course, when you add what
KDE and Gnome do to a system's interface configuration in general, it
just muddies the waters for everything else.

To be at least a little on-topic to the original subject, I'd like to
discover how to (for example) have a terminal or other app automatically
launch each time fvwm starts. I guess I'll find it in the multitude man
pages eventually. :-) Being able to Alt+Tab or equivalent between pages
(is that right? pages? or desktops?) would be nice, but I _do_ recall
seeing that addressed in the FAQ, so I'll have to read up on it.

-- 
+-----------------------------------------------------+
|  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: Dan Espen <[email-masked]>
Date: Thu, 08 Aug 2002 23:06:33 -0400

Len Philpot <[email-masked]> writes:
> one somewhere.

A complete tutorial might be several times larger than the man pages...

> pages eventually. :-)

AddToFunc InitFunction
+ I Exec xterm

The man pages are pretty helpful.
It helps a lot if you use some kind of tool to read the pages,
don't just type "man fvwm2" on the command line.
I find XEmacs to be a great man page browser.

-- 
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: Dominik Vogt <[email-masked]>
Date: Fri, 9 Aug 2002 11:07:39 +0200

> enough when it all comes together at once...

*Sigh*  Yes, the documentation is one of the biggest open issues
with fvwm, but we don't have the people and/or the infrastructure
to do it right.  We'd need somebody who is able and willing to set
up en environment in which the man page and other doc formats can
be generated from a single source.

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

---

From: Stephen Dennison <[email-masked]>
Date: Fri, 9 Aug 2002 12:40:43 -0400 (EDT)

What would you like to see in such a tutorial?

--s.r.d.

---

From: Cameron Simpson <[email-masked]>
Date: Sat, 10 Aug 2002 11:44:35 +1000

On 11:07 09 Aug 2002, Dominik Vogt <[email-masked]> wrote:
| *Sigh*  Yes, the documentation is one of the biggest open issues
| with fvwm, but we don't have the people and/or the infrastructure
| to do it right.  We'd need somebody who is able and willing to set
| up en environment in which the man page and other doc formats can
| be generated from a single source.

What kind of infrastructure did you have in mind?

I'm personally very fond of POD as a source format for most stuff, since
it's unassuming and very easy to edit and read, and readily generates
other formats. Does require perl though.

Idea: possibly a separate "fvwmtut" manual entry should accompany the main
man page?
-- 
Cameron Simpson, DoD#743        [email-masked]    http://www.zip.com.au/~cs/

A slipping sear could let your M203 grenade launcher fire when you least
expect it.  That would make you quite unpopular in what's left of your unit.
	- page 9 of the August 1993 issue of PS magazine, the US Army's
	  preventive maintenance magazine
--
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: Dominik Vogt <[email-masked]>
Date: Mon, 12 Aug 2002 01:39:27 +0200

> What would you like to see in such a tutorial?

That's a part of the job to figure that out.  Somethings that is
easy to understand and fun to read and yet gradually introduces
more advanced features to show fvwm's flexibility.

On Sat, Aug 10, 2002 at 11:44:35AM +1000, Cameron Simpson wrote:
> | up an environment in which the man page and other doc formats can

> other formats. Does require perl though.

I'm a complete newbie inrespect to documentation formats.  Some
basic requirements are:

 - Must be convertible to various other formats (man page, ps,
   html and possible GNU Texinfo) and must look good in these
   formats.
 - The tools must works on any system and should run out of the
   box.  Everybody must be able to edit the documentation.
 - The format should be reasonably easy to edit without any tools
   other than a text editor.

Perl is no problem, we already use it.

> Idea: possibly a separate "fvwmtut" manual entry should
> accompany the main man page?

Why not?  A real tutorial that comes with the sources would be
nice.  Several people have done some work in the past.  I
appreciate all this work a lot.  Everything is still in my inbox.
The biggest problem is that people do some work without
coordinating it on the fvwm-workers list, then dump the result on
the list in some random format that we neither have the tools for
and that isn't convertible, then vanish into thin air :-/

We need somebody that can spend some time on the documentation to

 * Introduce the documentation infrastructure.
 * Instruct us hackers how to use it.
 * Intergrates the necessary framework into the source tree
   (configure tests, "make" targets, etc.)
 * At least helps to convert the existing docs to that format.

And if (s)he wants to be even more helpful:

 * Examines all the existing documentation and puts in together in
   a nice and shiny new tutorial, short reference, commented
   exmaple configs etc.

I'd be willing to provide any help with the contents, but I can't
find the time and leisure to do everything myself.

Bye

Dominik ^_^  ^_^

---

From: Cameron Simpson <[email-masked]>
Date: Mon, 12 Aug 2002 16:01:42 +1000

On 01:39 12 Aug 2002, Dominik Vogt <[email-masked]> wrote:
| On Sat, Aug 10, 2002 at 11:44:35AM +1000, Cameron Simpson wrote:
| > What kind of infrastructure did you have in mind?
| > I'm personally very fond of POD as a source format for most stuff, since
| > it's unassuming and very easy to edit and read, and readily generates
| > other formats. Does require perl though.
| 
| I'm a complete newbie inrespect to documentation formats.  Some
| basic requirements are:
| 
|  - Must be convertible to various other formats (man page, ps,
|    html and possible GNU Texinfo) and must look good in these
|    formats.

It does all these, except texinfo, but it will emit latex if you really
care.

|  - The tools must works on any system and should run out of the
|    box.

if they have perl, definitely.

|    Everybody must be able to edit the documentation.

Yes. It's damn near plain text with very simple and unintrusive markup.

|  - The format should be reasonably easy to edit without any tools
|    other than a text editor.

Yep. That's what I like about it.

| Perl is no problem, we already use it.

Cool.

Will have to address the 2nd half of your message later.

Meanwhile, "man perlpod" will describe the format for you. Here's a shell
script with its own manual page inlined (I pull it out and format with
a script):

	http://www.zip.com.au/~cs/scripts/lz

Here's the HTML page that makes.

	http://www.zip.com.au/~cs/man/lz.1.html

The manual page looks exactly like a regular manual page.

The leading hashes aren't part of the format - they're just shell comments
to hide the POD from the shell. Typical pod is:

	=head1 A Heading

	Here's an example paragraph
	that will be filled (line flowed) by whatever backend format gets used.
	Here's a reference to the fvwm(1) manual page.
	Here's some literal (unfilled) text:

		DestroyFunc foo
		AddToFunc foo	Next

	Here's the next paragraph with a B<bold> word.

Very user friendly.

Academics get paid for being clever, not for being right. - Donald Norman

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 13 Aug 2002 00:30:33 +0000

We already use the pod documentation format in FVWM in perl tools:

  * fvwm-menu-directory
  * fvwm-menu-headlines
  * fvwm-menu-xlock
  * fvwm-perllib
  * all perllib classes
  * FvwmPerl

I would probably say more yes than no to use pod in all documentation,
but I don't see a lot of reasons for this.
Pod is pretty rich, but not as rich as the man page format.
As for me, both the man page format and pod are easy to write and read.

There are a lot of small things in pod (say, no center-justification in
man pages) that I don't like, it is just not configurable enough. I myself
even have somewhere a patched Pod::Man that fixes some annoyances, like
converting "run fvwm(1)" to "run the fvwm manpage", but it's not an option
for everyone to install it. Also fvwm-perllib fixes one bug in pod2man.

There is no easy way to define a plain-unformatted-lines text without
first padding it with at least one space, this looks ugly in SYNOPSYS and
other places. This padding feature is often misused, for example the pod
used in Pod::Parser class itself hardcodes the 12 spaces indentation,
which is bad if the output is html, not just man pages.

Of course if I would not be a pod fan, I would not create fvwm-perllib
that uses it in several interesting ways.

Regards,
Mikhael.

---

From: Felix Karpfen <[email-masked]>
Date: Tue, 13 Aug 2002 09:17:26 +1000

Dominik Vogt wrote:
> That's a part of the job to figure that out.  
>
2 cents' worth from a new arrival who badly needs such a tutorial.

The postings (that I have read) look at suitable formats.

But the real issue is _content|sequence of presentation_.

My recent efforts to learn to use "vim" may serve as an illustration.

My version of Linux installed vim-5.7.  That did all that I am ever
likely to need in an editor.  But the documentation was unhelpful.  I
opted to update to vim-6.0 because it came with an Online Manual.

The Manual has two parts:

        a Users Manual; and
        a Reference Manual.

and it is utterly superb.

An enormous amount of thought and effort must have gone into the
preparation of the Users Manual in selecting the order in which topics
are described and previously-described routines are shown in use at
later stages - helping newcomers to refresh what they had learnt and had
already forgotten again.

This posting adds nothing that is not obvious to the experts - the requested
project is of mammoth proportions.

And if wishes were horses, beggars would ride.

Felix Karpfen
-- 
Felix Karpfen
[email-masked]
Public Key 72FDF9DF (DH/DSA)