Subject: Fvwm Decors?

From: Dan Espen <[email-masked]>
Date: Mon, 16 Apr 2001 22:19:00 -0400

I've been playing around with sample.fvwmrc/decor_examples.

I recently changed it so that the decor definitions are:

modular,
create their own menu entries,
have a way to undo themselves.

I have a  new version that:

remembers its  setting thru restarts,
uses FvwmCpp to  read decor definitions,
supports system wide and user level decor definitions,
can be included in the default startup with little overhead,
can be turned on and off thru a menu,
could be integrated into fvwm.

This is not a theming engine, there is no gui to create decors.

Attached is the decor driver and 2 decor files.  (I have 5 more decors
but they are all need special icons.)

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214             E-mail: [email-masked]
Piscataway, NJ 08854                       Phone: (732) 699-5570

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 19 Apr 2001 11:38:43 +0300

> have a way to undo themselves.

Dominik previously said that he wants to remove decors and make the
current TitleStyle, ButtonStyle and BorderStyle to be Style options.

This is the second reason why we don't use decors in fvwm-themes.
The main reason not to use decors is that decors are really redudant if
only one is used at any time, like in your setup.

> could be integrated into fvwm.

If this means to add more examples, this is fine.
If "integration" means adding this to ConfigFvwmDefaults, I am against.
If it means adding it to ConfigFvwmSetup, you may do this if you feel
strong about this, but I would not start to add new themability setups.

Creating a functional universal theme framework is not an easy work.
The problems are not limited only to decorations or menustyle; fvwm-themes
gives a unified solution for window decorations, background, bindings,
colors, cursors, globalfeel, menus, menustyle, styles, binding applications
and any new components which may be added without changing a theme engine.
Even a solution for window decorations is more flexible than in this setup,
there are 3 separate components: window buttons, window look, colorsets.
so you may use any decorations with any buttons with any colors (useful).
Or be able to define an order of titlebar buttons (in the next 0.4.3).

> This is not a theming engine, there is no gui to create decors.

This is still a new theming setup, why to add it to FVWM as mandatory?
The plus of this setup is that it's simplier, but it will become complex
once you will want to make it work without glitches for many configs.
The reasons which I see why not to add this themability setup are:

  1) It still requires to comply with some rules in dividing user fvwmrc,
     but it is incompatible and much less functional than fvwm-themes.
  2) It does not use colorsets, so a pager can't reuse colors used in
     decors for mini-window colors. Also should menu (and other) colors
     be changed together with decor colors? Probably, yes.
  3) Many rc files and other resources (like images) are required to be
     installed together with FVWM even if they are never used by a user.
  4) Decors (and menustyles) in this setup are already maintained in
     fvwm-themes, new examples may be added to fvwm-themes as themes.

Several days ago I added decorations for 2 new themes, brushedmetal and
nanogui (in cvs), 2 more will come soon. If you send me decoration examples
of your 5 decors, I or someone else (maybe you) may add more themes.
It is ok if a theme should include more images or other resources.

> but they are all need special icons.)

Regards,
Mikhael.
--
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: Sat, 21 Apr 2001 11:32:05 -0400

> current TitleStyle, ButtonStyle and BorderStyle to be Style options.

Except for the name, decors aren't essential to what it does.
The "decor" files that it reads in can do whatever is wanted as
long as the remove hook undoes it.

>      fvwm-themes, new examples may be added to fvwm-themes as themes.

I'm drawn to what I created just because it is simple.
I don't see how it will ever become complex, but I could be wrong.
The decors could be complex, but the add and remove hook concept
seems like it could remain as simple as it is.

If it was  added to FVWM  as mandatory, all  that would happen is that
about a 15  additional lines would  be read during startup, a  small
menu would be built, and one read for the users .DecorCurrent would be
done.  If decors hadn't been turned on, nothing else would happen.

Your feedback is exactly what I was looking for.
I'm not sure its a good thing either, or I would have just gone
ahead and committed it.

I'm  not sure its a good  idea to commit it as  an example either, its
a little hard to understand for an example.  I'll have to give some
thought as to what I should do with it vs. fvwm.

I find it perfect for my own use.  My users don't want their entire
configuration revamped, just a little border/menu adjustment.
Most of them are quite happy with the choice of blue marble borders,
or W95 plainness.

Thanks for sharing your thoughts, thats exactly the kind of feedback
I was hoping for.