Subject: FVWM: weird xterm behavior

From: Brad Giaccio <[email-masked]>
Date: Wed, 20 May 1998 09:39:35 -0400 (EDT)

I don't know if anyone else knows this but some of the nwere xterms give
you an option for active icons.

But I seem to get a bit of odd behavior with them when I use fvwm2.
Basically I bring up the xterm do some stuff and its find until I resize.
As soon as I resize it goes craxy and it shrinks down to the 4 handles +
the cursor and scrollbar width.  Anyone else see anything likes this and
can tell me what I did wrong?  it only seems to happen under fvwm.
Solaris CDE, and twm don't do it.

Thanks,
Brad

--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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]
Date: Wed, 20 May 1998 11:18:07 -0400 (EDT)

I think it would be a useful thing if fvwm could support installable
packages.  A package would be a set of related files needed to
configure fvwm in some special way.

What I have in mind is to add a new command in fvwm's configuration
file syntax:

    AddPackage Name [Preprocessor command]

	name is the name of a directory somewhere in the current
	ModulePath.  The command interpreter adds this directory to
	the current ModulePath, PixmapPath, and IconPath.  This
	directory must have a "package.rc" file within it that may
	contain fvwm configuration commands.

	The preprocessor command, if specified, would be some program
	that would be used to preprocess the package.rc file.  FvwmM4
	and FvwmCpp come to mind here.  If not specified, the
	package.rc file is read directly by the command interpreter.

	By convention, the package.rc file only defines menus,
	functions, and module configurations, all prefixed wherever
	possible by the package directory name.  Also, by convention,
	a function named Init (prefixed by the packagethe name) is
	used to "implement" the package.

	The files within the package directory could contain whatever
	is necessary to implement the package...  module executables,
	pixmaps, bitmaps, etc.

As an example, let's create a Windows 95 look and feel package.  To do
this, we would need five files:  three pixmap files (for the minimize,
maximize, and close buttons), a README file (to explain what the
package is for, and to explain how to install it) and a package.rc
file.  I won't include the contents of the pixmap files, but show how
the package would be specified:

- File:  Win95/README
    Win95 Example Package

    This package implements a Windows 95 look and feel for fvwm.
    
    Installation:

	This assumes that you have installed this package as
	/usr/lib/X11/fvwm/Win95.  First, make sure that
	/usr/lib/X11/fvwm is in your ModulePath:

	    ModulePath /usr/lib/X11/fvwm

	Then, to have fvwm use the Windows 95 look and feel, add the
	following two lines to the bottom of our .fvwm2rc file:

	    AddPackage Win95
	    Win95Init

- File:  Win95/package.rc:
    # Win95 Look and Feel package:

    DestroyDecor	Win95
    AddToDecor	Win95
    +	WindowFont	-adobe-helvetica-bold-r-normal--12-120-75-75-p-*-iso8859-1
    +	TitleStyle	LeftJustified
    +	TitleStyle	ActiveUp (Solid Navy -- flat) \
			    ActiveDown (Solid Navy -- flat) \
			    Inactive (Solid grey51 -- flat)
    +	ButtonStyle 1	MiniIcon -- Flat
    +	ButtonStyle 2	Pixmap win95-close-full.xpm
    +	ButtonStyle 4	Pixmap win95-maximize-full.xpm
    +	ButtonStyle 6	Pixmap win95-minimize-full.xpm
    +	BorderStyle	Active -- HiddenHandles NoInset
    +	BorderStyle	Inactive -- HiddenHandles NoInset
    +	HilightColor	white grey60
    +	ButtonStyle 1	- Clear MWMDecorMenu
    +	ButtonStyle 2	- Clear
    +	ButtonStyle 4	- Clear MWMDecorMax
    +	ButtonStyle 6	- Clear MWMDecorMin
    +	ButtonStyle All	-- UseTitleStyle
    +	ButtonStyle right ActiveUp (-- Flat) \
			      ActiveDown (-- Raised) \
			      Inactive (-- Flat)

    DestroyFunc	Win95Init
    AddToFunc	Win95Init \
      "I"	RemoveAllButtons
    + "I"	Style "*"	UseDecor Win95, ForeColor Black
    + "I"	Style "*"	Button 1, Button 2, Button 4, Button 6
    + "I"	Style "*"	NoButton 0, NoButton 3, NoButton 5, \
				NoButton 7, NoButton 8, NoButton 9
    + "I"	MenuStyle	Black grey75 grey40 -adobe-helvetica-medium-r-*-120-* mwm
    + "I"	Mouse 0	1 N	Menu Window-Ops Close
    + "I"	Mouse 0	2 N	Close
    + "I"	Mouse 0	4 N	Maximize 100 97
    + "I"	Mouse 0	6 N	Iconify
    + "I"	Mouse 3	6 N	Replace
    + "I"	Exec xsetroot -solid cyan4
    + "I"	Recapture
- File:  Win95/Win95-close-full.xpm
    [ data not included in this message ]
- File:  Win95/Win95-maximize-full.xpm
    [ data not included in this message ]
- File:  Win95/Win95-minimize-full.xpm
    [ data not included in this message ]

This package directory should be stored somewhere within the
ModulePath (or we could also create a 'PackagePath' keyword for this
purpose!), and it could be read by the command:

    AddPackage Win95

To get the Windows 95 look and feel, one simply needs to execute the
package's initialization function:

    Win95Init

(This could be anywhere where an fvwm function could be executed... in
the main RC file, or within a menu, for example.)

Since the package is defined to be an entire directory, the package
could be simply distributed as a gzip'ed tar file.  People that want
to tinker with the package will know exactly where to go to find the
file(s) to change.

Packages aren't limited to look and feel issues... they could be used
to specify some neat FvwmButtons configuration, some common menus,
etc.  People could then pick and choose the packages that they want on
their systems.

Fvwm could contain some packages in its distribution to supply
examples of how packages could be implemented.  We could also maintain
a repository for other FVWM packages.

Using the Win95 package that I have just outlined, an answer to a FAQ
(How do I get fvwm to look like Win95?) could be answered easily
(download the package http://some.site/fvwm/packages/win95.tar.gz and
follow the README file within it).

What do people think of this idea?

-- 
(void) lar3ry();                                      [email-masked]

     "Sometimes it happens.  People just explode.  Natural causes."

---

From: Brady Montz <[email-masked]>
Date: 20 May 1998 09:09:55 -0700

> What I have in mind is to add a new command in fvwm's configuration

...

> purpose!), and it could be read by the command:

...

> What do people think of this idea?

Sounds like a good idea. I wonder if it is a good idea to overload the
modulepath for this, since a package really isn't a module. I'd prefer using
PackagePath. For example, I typically have my modules somewhere in my ~/bin
hierarchy, since they are platform dependant binaries (I have subdirectories
in ~/bin for each OS/ARCH combination I use), but would probably want my
packages in a ~/.fvwm directory. 

-- 
 Brady Montz
 [email-masked]

---

From: Brady Montz <[email-masked]>
Date: 20 May 1998 09:15:32 -0700

> configure fvwm in some special way.

One final thing. One goal I have is to be explore writing actual modules which
can change the look+feel of fvwm, probably implemented as dynamically loaded
libraries. So, for example, somebody could decide at fvwm run-time whether
they want the texuture code loaded or not, depending on their display depth. I
suspect this could make fvwm more streamlined and organized. Anyhow, it seems
that this package idea would map pretty easily to a way to specify which
modules are loaded.

---

From: "Donald H. Locker" <[email-masked]>
Date: Wed, 20 May 1998 12:38:58 -0400

Hmmmm.

Can't we

AddToFunction AddPackage "I" Read $0
+                        "I" Exec $0.Init

(or some such)

Donald.

---

From: Bruce Stephens <[email-masked]>
Date: 20 May 1998 17:41:43 +0100

> Sounds like a good idea. I wonder if it is a good idea to overload
> the modulepath for this, since a package really isn't a module.

I agree.  Why "packages", though---aren't these going to get called
"themes", and shouldn't we just give in, and call them "themes"?  

Or are "themes" something else again?

---

From: [email-masked]
Date: Wed, 20 May 1998 13:25:21 -0400 (EDT)

> AddToFunction AddPackage "I" Read $0

Where is the file read from?  From my understanding, it would be in
whatever directory the rc file was found.  Plus, this hasn't added the
directory to the icon and bitmap path, which means that I will have to
install the pixmaps associated with, say, the Win95 look and feel into
another directory.

What I was suggesting was some sort of standardized way of packaging
things for fvwm.  I cannot tell you how many times I've looked at
screen shots of various wm's with their "attached rc files" and hunting
through the rc files finding out how a particular effect was achieved. 
And these RC files may name a certain pixmap file, but finding those
pixmaps can be a hassle.

Having a standard way to package these things could allow people to
display a screen shot and a minimalist package to achieve a particular
effect.  Not everybody is going to create a specialized "AddPackage"
function for this; it's better if fvwm directly supported it so
everybody can use a package without having to write the function first.

and...

On 20 May, Bruce Stephens wrote:

> Why "packages", though---aren't these going to get called

Themes would seem to be what "decors" are in fvwm -- and I didn't want
the idea to be limited to just look and feel.

I can think of a number of useful "packages" for fvwm... win95, mac,
motif look and feels are just a start.  How about a package that uses
FvwmPager and FvwmButtons to create a CDE work bar?  How about a package
that uses FvwmButtons and FvwmIconMan to create a Win95 style task bar? 
(Pssssst, Brady...  FvwmIconMan doesn't support the use of multiple
confurations like 'Module FvwmButtons PagerButtons' does!)

Another example... what is the big difference between fvwm95 and fvwm2?
The Win95 look and feel.  Also, they incorporated a FvwmTaskBar module,
which Chuck brought into 2.0.46.  Why can't these two projects be
merged back into a single window manager with an supplied package that
optionally provides the fvwm95 look?