Subject: GSFR: splitting behaviour from appearance

From: Tim Phipps <[email-masked]>
Date: Mon, 08 Mar 1999 12:00:10 +0000

In the midst of rebuilding FVWMBorders I've started to have thoughts
about the GSFR.

There seems to be a bit of confusion between the appearance style flags
and decors.  What's the group feeling about making Decors mandatory and
moving the appearance style stuff to decors?

What I mean to move is:

BorderWidth, HandleWidth, NoTitle/Title, Nohandles/Handles, Color,
ForeColor, BackColor, MWMButtons/FvwmButtons, MWMBorder/FvwmBorder,
MWMDecor/NoDecorHint, NoButton/Button, 

and to leave:

NoIcon/Icon, MiniIcon, IconBox, IconGrid, IconFill,
WindowListSkip/WindowListHit, CirculateSkip/CirculateHit, Layer,
StaysOnTop/StaysPut, Sticky/Slippery, StartIconic/StartNormal,
StartsOnDesk/StartsOnPage/StartsAnyWhere, IconTitle/NoIconTitle,
MWMFunctions/NoFuncHint, OLDecor/NoOLDecor, HintOverride/NoOverride,
StickyIcon/SlipperyIcon, SmartPlacement/DumbPlacement,
RandomPlacement/ActivePlacement, DecorateTransient/NakedTransient,
SkipMapping/ShowMapping, UseDecor, UseStyle, NoPPosition/UsePPosition,
Lenience/NoLenience,
ClickToFocus/SloppyFocus/MouseFocus|FocusFollowsMouse.

My motivation for this is that Decors can change a lot of the visual
appearance of windows without a Recapture, but not quite everything.
Doing this move would make the look be controlled by decors and the
behaviour controlled by the Style command.  It might also make things
more consistent if the ButtonStyle, TitleStyle, BorderStyle,
HilightColor and WindowFont only worked as part of AddToDecor rather
than as standalone commands (as well as part of AddToDecor).

I realize this would break existing fvwmrc scripts, but it would make
understanding how to configure the look easier.

A smaller change would be to make the BorderWidth, HandleWidth,
NoTitle/Title, Nohandles/Handles, Color, ForeColor, BackColor,
MWMButtons/FvwmButtons, MWMBorder/FvwmBorder, MWMDecor/NoDecorHint,
NoButton/Button parts of style into standalone commands like
Button/Title/Borderstyle.

Any thoughts?

Cheers,
Tim.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Dan Espen <[email-masked]>
Date: Mon, 08 Mar 1999 08:29:09 -0500

> understanding how to configure the look easier.

If the config file breakage can't be easily repaired with greps/seds,
(invisible to the users I support), I'm against it.

Can't these things exist as both styles and decors?

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Tim Phipps <[email-masked]>
Date: Fri, 12 Mar 1999 16:43:01 +0000

> (invisible to the users I support), I'm against it.

mmmm, too difficult for me to think of a way.

> Can't these things exist as both styles and decors?

No reason why not, it make for a bit of redundancy but after the GSFR we
won't need a whole int for the border widths so it's probably no big
deal.

Would the decors override the style?

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Fri, 12 Mar 1999 11:56:59 -0500

> Would the decors override the style?

Doubtless there is some point I am missing.

If you set something with a style and then do a "style usedecor"
the last thing processed should override.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]