Subject: Re: FVWM Decor FAQ

From: "Paul D. Smith" <[email-masked]>
Date: Fri, 17 Jan 97 18:31:35 EST

I just spent a while trying to decipher the new stuff, including Decor.

I think one of the reasons it's confusing is that it's not clear at all
what the distinction between a Decor and a Style is, when you should use
one or the other, and basically why they are two different things and
what each is good for.

Also, it seems that everything _except_ Style has gone to the new
"AddTo" format (with the "+" lines), which is inconsistent.

And why is there only one AddToFunc, AddToMenu, AddToDecor, but there's
a distinction between ButtonStyle and AddButtonStyle?  I don't get that.

And, as I said before, some of the syntax uses this new (), --, !
notation and some doesn't (like Style doesn't use !, it has multiple
values for the opposite "flag" types).  That's also confusing.

Why do you define the colors to HilightColor as <c1> <c2>, but the
colors to the Style Color option as <c1>/<c2>?  There's just a lot of
inconsistency and even some redundancy, I think, in the config file
language now.

I think that somewhere there needs to be a very short overview: "Use
ButtonStyle to define buttons on the window frame border; use
AddButtonStyle to modify attributes of an existing ButtonStyle; use
AddToDecor to make a new Decor; use UseDecor to apply a Decor to a
Style; use UseStyle to `duplicate' a style", etc.

Also, someone should to rewrite the system.fvwmrc file to maybe use
Decor and/or Style "correctly" as an example; here's how I changed my
~/.fvwm2rc (obviously, comments more than welcome :) after I (think I)
figured out Decor and UseStyle:

  ### Standard Window Configuration

  AddToDecor Standard
  +       HilightColor    Black DeepSkyBlue
  +       WindowFont      -adobe-times-bold-r-*-*-14-*-*-*-*-*-*-*
  +       ButtonStyle 1   ActiveUp (Pixmap fvwm2/mini.destroy.xpm) \
                          ActiveDown (Pixmap fvwm95/mini-exp.xpm) \
                          Inactive (Pixmap fvwm2/mini.destroy-alt.xpm)
  +       ButtonStyle 2   Pixmap fvwm2/mini.maximize-vert.xpm
  +       ButtonStyle 4   MiniIcon

  Style Standard  UseDecor Standard, \
                  BorderWidth 5, Color LightSkyBlue2/RoyalBlue4, \
                  DecorateTransient, HintOverride, \
                  Icon fvwm2/default.xpm, MiniIcon fvwm2/jball.xpm, \
                  StickyIcon, IconBox 3 -20 -1 -1, \
                  RandomPlacement, SmartPlacement, \
                  MWMDecor, MWMFunctions

  Style Naked     WindowListSkip, Sticky, NoTitle, NoHandles, BorderWidth 0

  ### Application-specific decoration styles and window options

  Style "*"           UseStyle Standard

  # FVWM Modules

  Style "Fvwm*"       UseStyle Naked
  Style "FvwmTalk"    WindowListHit,  Slippery, Title, BorderWidth 5
  Style "FvwmConsole" WindowListHit,  Slippery, Title, BorderWidth 5
  Style "Tkgoodstuff" UseStyle Naked

  # Individual application styles & icons

  Style "*faces"      UseStyle Naked, StaysOnTop
  Style "*lock"       UseStyle Naked
  Style "XSysStats"   UseStyle Naked
  Style "XMcd"	      UseStyle Naked

  Style "ical_alarm"  StaysOnTop

  Style "*XTerm"      MiniIcon fvwm2/mini.xterm.xpm
  Style "XTerm"       Icon x/xterm-basic.xpm
  Style "rootXTerm"   Icon t/term2.xpm
  Style "sysXTerm"    Icon t/term2.xpm
  Style "rxvt"        Icon t/term2.xpm

  Style "xman"	      Icon x/xman.xpm, MiniIcon fvwm2/mini.xman.xpm

  Style "Tgif"        Icon desc/cl-48/draw.xpm
  Style "Xarchie"     Icon x/xarchie.xpm, MiniIcon fvwm2/mini.xarchie.xpm
  Style "Mosaic"      Icon w/www-shape.xpm, MiniIcon fvwm2/mini.netscape.xpm
  Style "Netscape"    MiniIcon fvwm2/mini.netscape.xpm
  Style "Emacs"	      Icon g/gnu.xpm, MiniIcon fvwm2/mini.gnu.xpm

This, obviously, is not my whole config, but it's all the decor/style
part.

Basically I create a "Standard" Decor and a "Standard" Style (that uses
the Standard decor), then I define all windows to use the Standard Style.

Then I have another Style, Naked, that I use for apps that have no
border (button bars, CD player, XFaces, etc.)

The idea, I guess, is I could make other Styles and/or Decors and switch
them pretty easily.

Well, anyway, FWIW.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
     These are my opinions--Bay Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: [email-masked] (Albrecht Kadlec)
Date: Sat, 18 Jan 97 01:24:31 +0100

>>>>> Paul D Smith writes:

Paul, first of all: very good points.

P> I just spent a while trying to decipher the new stuff, including Decor.
P> I think one of the reasons it's confusing is that it's not clear at all
P> what the distinction between a Decor and a Style is, when you should use
P> one or the other, and basically why they are two different things and
P> what each is good for.

P> Also, it seems that everything _except_ Style has gone to the new
P> "AddTo" format (with the "+" lines), which is inconsistent.

P> And why is there only one AddToFunc, AddToMenu, AddToDecor, but there's
P> a distinction between ButtonStyle and AddButtonStyle?  I don't get that.

because the AddButtonStyle part was added by Andrew (minimal change
policy, or Chuck won't consider the patch, since it's to big to work
through  - I fixed a whole lot of bugs at once and added some
features, but Chuck simply didn't include it. - lots of parsing bugs
could simply be fixed by modifying MatchToken and CmpToken)

P> And, as I said before, some of the syntax uses this new (), --, !
P> notation and some doesn't (like Style doesn't use !, it has multiple
P> values for the opposite "flag" types).  That's also confusing.

chuck is working on it. I hope he'll use the ! instead of the
unreadable "NoNormal", "Normal", "OnlyNormal", for WindowList again.

I did it like this originally (my WindowList rewrite)
	+ or & means: this option is required,
	- or ! means: this option is rejected (required to be off)
	     . means: don't care for this option
it was "too unreadable" :-)

anyway. Chuck should make his decision and stay with it throughout all
of .fvwm2rc.

P> Why do you define the colors to HilightColor as <c1> <c2>, but the
P> colors to the Style Color option as <c1>/<c2>?  There's just a lot of
P> inconsistency and even some redundancy, I think, in the config file
P> language now.

e.g: you can say 
	Color fore/back
or 
	ForeColor fore
	BackColor back

I was always wondering about that one :-)

P> I think that somewhere there needs to be a very short overview: "Use
P> ButtonStyle to define buttons on the window frame border; use
P> AddButtonStyle to modify attributes of an existing ButtonStyle; use
P> AddToDecor to make a new Decor; use UseDecor to apply a Decor to a
P> Style; use UseStyle to `duplicate' a style", etc.

so what exactly is the difference between a decor & a style, as they
both affect appearance of a window ?

decor seems to be the complex options (with parameters or lots of data),
	while
styles are mostly binary options (small parameters)

Why not UseStyle & CopyStyle ?

I don't see them as orthogonal concepts, anyway.

But besides all these inconsistencies & deficiencies:
fvwm2.0.44 is a lot more consistent than the previous versions.
Many changes have taken place which didn't even touch the surface.
Yet they were even more important than some of the bug fixes and added
features. Chuck has done a very good job in keeping the project running.

regards,
albrecht
-- 
There can be only one and a half. --  The highlander to a recently
					     halved Kurgan.

---

From: Andrew Veliath <[email-masked]>
Date: Fri, 17 Jan 1997 19:28:40 -0500 (EST)

It's been what -- three days since fvwm 2.0.44 has been released???

(feels like two months :-)

> "AddTo" format (with the "+" lines), which is inconsistent.

The reason that some things have gone global is because there aren't any
more style flags (yet).  There is a slight confusion between Style and
ButtonStyle, for example, but this is due to the flag limitation, which is
to be addressed by Chuck after version 2.1.

Many of the things you've mentioned I've been forced to think about at one
time or another during implementation, but factors which caused me to make
certain decisions include backwards compatibility, practicality, and being
able to _not_ use any of the options (most important).

> a distinction between ButtonStyle and AddButtonStyle?  I don't get that.

Functions, menus and decors do not belong to anything.  They are only
assigned or called from other things.  In this respect, they are global.
Button/title/border styles belong to decors.

> values for the opposite "flag" types).  That's also confusing.

It's not entirely consisitent, but once you get the hang of it it's not
bad.  I did this since it made code a bit smaller and more convienent.
Might be something too look into after 2.1.x though -- more consolidation
of parsing.

> inconsistency and even some redundancy, I think, in the config file

HilightColor has always been like that, unless someone changes it.  There
has always been a lot of inconsistency and redundancy, and it won't go
:-).  Part of the problem is retaining some sense of backward
compatibility for fvwm2. 

You can't expect perfection -- no one works on this stuff full-time (also
it would take much longer :-).  These things are meant to be practical,
i.e., you write something in the RC and it operates in a particular
manner.  If you want more you could always go with gwm or something.  If I
wrote a window manager from scratch I'd probably include something close
to a Turing-complete language written in lex/yacc.

The main reason that for example ButtonStyle has become somewhat complex
is simple:  it still works with original button definitions.

> Style; use UseStyle to `duplicate' a style", etc.

This is reasonable, and I think would probably be most effective.  Let me
see if I can come up with a man page section for that.  If you can, I'll
send it to you for comments.

I really didn't think there would be as much interest in this Decor stuff
when I wrote it.  It is just a feature, and you can use it or ditch it.
However, since do seem to be interested, the future is wide open.

The idea behind UseDecor is that you can make sets of window
title/button/border/windowfont/hilightcolors and assign them to any
window.  That's it.  It's a lot of stuff which does take some time getting
used to. 

I wouldn't expect anyone to understand everything in one day about decors
any more than I'd expect anyone learning everything about Emacs in 1 year. 
I wrote the Decor stuff and even I haven't learned everything about it;
I've seen examples which I've never thought of being posted recently.

Let me see if I can explain the AddButtonStyle to you a bit more.  Imagine
a stack of styles, each painted on top of one another.  If I give a
ButtonStyle command with a style in there, than it clears the stack; i.e.:

ButtonStyle 1 Solid Blue

This would give me a solid blue button.  Say I wanted a pixmap over that
blue button.  Then I can say: 

AddButtonStyle 1 Pixmap a.xpm

And say I wanted a second left justified pixmap over that, yielding a
stack which holds three styles: 

AddButtonStyle 1 Pixmap b.xpm -- left

Then, a fourth style say is added, which is the default vector button of
button 3:

AddButtonStyle 1 Default 3

Resulting in the full definition (this does the same thing for all button
states since no state is specified for any definition):

ButtonStyle 1 Solid Blue
AddButtonStyle 1 Pixmap a.xpm
AddButtonStyle 1 Pixmap b.xpm -- left
AddButtonStyle 1 Default 3

That's it.  The same is possible with TitleStyle if EXTENDED_TITLESTYLE is
enabled. 

Say I wanted to use the TitleStyle for button 1 without clearing the
abutton stack:

ButtonStyle 1 -- UseTitleStyle

To get rid of UseTitleStyle

ButtonStyle 1 -- !UseTitleStyle

> figured out Decor and UseStyle:

True, some examples are needed.  But the problem is that these things are
quite flexible, and I could give you a pretty simple example as above or a
very complex one.  I guess the key would be to get as many examples as
possible.  But someone has to make an example repository. 

It would be nice if someone could setup some sort of fvwm2 example
repository with a http inteface (seriously!). 

The main thing right now is to fix bugs; this is the only the first beta
release of the decor stuff in fvwm2 :-). 

Regards,
Andrew

--
Andrew Veliath <[email-masked]>        http://www.rpi.edu/~veliaa
One day, all forms of communication will be superseded by a FAQ.
Finger for PGP Public Key
Key fingerprint =  51 56 5D 3E 51 43 8B 74  7C B2 E4 B6 84 8E 8B 08

---

From: "Paul D. Smith" <[email-masked]>
Date: Sun, 19 Jan 97 13:35:31 EST

%% Andrew Veliath <[email-masked]> writes:

First, let me clear that I certainly appreciate all the work everyone
has done on everything: decors, enhanced button styles, miniicons, etc.

My comments are meant to be purely constructive criticism of the
existing rc file language--I'm a language/compiler person :)

  >> "AddTo" format (with the "+" lines), which is inconsistent.

  av> The reason that some things have gone global is because there aren't any
  av> more style flags (yet).

I'm not talking about global vs. non-global things; I absolutely
understand the issues surrounding the Great Style Flag Rewrite.

I'm coming from a purely syntactic area: creating functions, menus,
etc. uses the "AddToXXX", with "+ line", while creating Styles uses a
completely different syntax of comma-separated elements.  I'm not sure I
see a reason for the distinction.

Also, I understand there's a backwards-compatibility issue: if that's
all it is perhaps we can address it that way.

  >> a distinction between ButtonStyle and AddButtonStyle?  I don't get that.

  av> Functions, menus and decors do not belong to anything.  They are only
  av> assigned or called from other things.  In this respect, they are global.
  av> Button/title/border styles belong to decors.

Yes, but you can declare them outside of decors, too, making them global
at least in that sense.

  av> You can't expect perfection -- no one works on this stuff full-time (also
  av> it would take much longer :-).  These things are meant to be practical,

No, I know.  I'm simply offering observations, from a "fresh"
perspective and from someone who's written a lot of little languages and
compilers (and some not so little), on things that could be improved or
currently seem inconsistent.  No blame, just commentary.

  av> This is reasonable, and I think would probably be most effective.  Let me
  av> see if I can come up with a man page section for that.  If you can, I'll
  av> send it to you for comments.

Love to read it.

  av> I really didn't think there would be as much interest in this Decor stuff
  av> when I wrote it.  It is just a feature, and you can use it or ditch it.
  av> However, since do seem to be interested, the future is wide open.

I think there's an interest in constructing RC files which adhere to
object-oriented principles, in order to make them (the RC files) more
modifiable, readable, and usable.

It seems to me that Decors and "anonymous" Styles (styles which don't
necessarily apply to a window, but are used for UseStyle operations),
together, go a long way in that direction: you create window
border/functionality "classes", then assign them to various instances of
windows.  People understand and like that idea (at least I do).

---

From: Andrew Veliath <[email-masked]>
Date: Sun, 19 Jan 1997 19:09:55 -0500

> windows.  People understand and like that idea (at least I do).

No problem Paul.  This is exactly what I was/am aiming for.  I come from
an OO background, and this is why I recently made that fix to UseStyle
so it worked :-).

At this stage however, I'm not going to have much time for anything but
bug fixes for the stuff I've contributed to fvwm2 (I need to devote much
more time to my eng. degree now -- however, sometimes you know how it is
if you suddenly think of a 'that would be cool' feature it just has to
be done :-).  If you have some time (you definately seem interested,
which is good :-), you might consider working up some solutions for
those aforementioned deficiencies and posting them to the workers list.

Later,
Andrew

---

From: Ian Spielman <[email-masked]>
Date: Thu, 23 Jan 1997 06:31:58 +0000 (GMT)

I guess the title sums it up well. This is a patch to fvwm that makes the 
icons have the shaded look that is typical to NextStep. I acteded without 
shame and took most of the code from AfterStep. As with Afterstep all the 
icons need to have atleast one pixel that is of color "None". I have been 
using this patch agenst fvwm 2.0.43 for 5 months with no problems. My 
goal is to make this yet another style; I.E. shaded icons, but for now it is 
an all or nothing deal. 

If there are any questions or problems please address me and not the 
mantaner(s) of FVWM. They have enough work. 

This patch is posted on my webpage along with a screen shot.

http://hepserver.nhn.ou.edu/~spielman/fvwm/index.html

Have fun,
	Ian Spielman