Subject: ewmh configuration

From: Olivier Chapuis <[email-masked]>
Date: Fri, 16 Nov 2001 20:17:01 +0100

Hello,

Now the ewmh support should be configurable (and tested).
At present time the only new configuration stuff is that there
is a new context "D" for bindings onto an application of Desktop
type as kdesktop and Nautilus desktop (I've never tested the
Nautilus desktop).
Here my plan. I need to know if the chosen name as well as the
behavior of these config commands are acceptable. Maybe there are
to many styles.
Also, as ewmh is off by default, most of the defaults cause fvwm
to enable some features. However, maybe in the future (when GNOME 2
will be widely used) ewmh will be on by default (this happened with
GNOME 1 support) and the default should be changed. This is a bit
problematic.

This is just a "first" draft (sorry for the English) I will try
to be more careful with the manual page.

New styles:
----------

* RejectStayOnTopHints / AcceptStayOnTopHints
RejectStayOnTopHints causes fvwm to ignore initial (ewmh) hints which ask
to put an application into the default StaysOnTop Layer. AcceptStayOnTopHints
which is the default causes fvwm to accept this hint.
(note: this hint is not a part of the ewmh spec but it is used by KDE).

* MiniIconOverride / NoMiniIconOverride
MiniIconOverride causes fvwm to ignore the mini icon provided by the
application and to use the mini icon defined by the MiniIcon style.
NoMiniIconOverride reestablish the default which is to use the mini
icon provided by the application.

* IgnoreEwmhIcon / ForceEwmhIcon / UseEwmhIcon
These styles extends the  IconOverride / NoIconOverride / 
NoActiveIconOverride styles.
ForceEwmhIcon causes fvwm to use the ewmh icon hint (if any)
in priority even if the IconOverride style is used or the application have
an icon window (and NoIconOverride or NoActiveIconOverride is used).
IgnoreEwmhIcon causes fvwm to do as if the application has no ewmh icon
hint at all.
UseEwmhIcon is the default and causes fvwm to use the ewmh icon hint
if the application have no icon window and the IconOverride style is
not used.

* DoNotSetMiniIcon / SetMiniIcon
If an application does not provide an ewmh (mini) icon hint, then
fvwm sets such hint with the mini icon provided by the MiniIcon style.
This cause ewmh compliant pager and taskbar to use the same mini
icon as fvwm use.
DoNotSetMiniIcon disable this feature and SetMiniIcon reestablish the
default.

* DoNotSetIcon / SetIcon
As above for icon, but the icon used is the icon that use fvwm
(determined by the IconOverride / NoIconOverride / NoActiveIconOverride
style) but the icon window that can provide an application is ignored.

* NoEwmhAnimate / EwmhAnimate
If the NoIcon style is used and an ewmh compliant taskbar provide
an icon position hint, then fvwm2 ask FvwmAnimate to animate the
(de)iconification using this hint. NoEwmhAnimate disable this feature
and EwmhAnimate (the default) enable it.

* IgnoreEwmhWMStateHints / UseEwmhWMStateHints
IgnoreEwmhWMStateHints causes fvwm to ignore the ewmh _NET_WM_STATE when
an application is mapped. Such hints may ask to map the application sticked,
shaded and/or maximized, to put the window in the window SkipList and/or
to consider the application as a modal application. UseEwmhWMStateHints
reestablish the default which is of course to use these hints

* IgnoreEwmhWindowTypeHints args
Where args is a space separated list constitued by the following key word
Desktop, Dialog, Dock, Menu, ToolBar. This cause fvwm2 to ignore the
correspondig _NET_WINDOW_TYPE hints (see my future email on  window
type config). This style is destructive: to reestablish the default
which is to do not ignore any of these hints just give an empty args
and the two lines:
IgnoreEwmhWindowTypeHints Menu Dialog
IgnoreEwmhWindowTypeHints ToolBar
cause to ignore only the ToolBar window type.
Is this really needed??

* Note on working area:
Without ewmh support the working area is the full visible screen
(or all your screens if you have a multi head setup and you use Xinerama).
However, a compliant application as a panel can ask to reserve space
at the edge of the screen. If it is the case, the Working Area is  your
full visible screen minus these reserved space. If the panel can be
hidden by clicking by a button the Working Area does not change (as
you can unhide the panel at any time), but the Dynamic Working Area
is updated so that the reserved space by the panel is removed (and readded
if you unhide the panel). Note that an autohide panel has a fixed reserved
space.  

* NoWorkingAreaPlacement/ DynamicWorkingAreaPlacement / WorkingAreaPlacement
DynamicWorkingAreaPlacement causes fvwm to use the Dynamic Working Area
for window placement as NoWorkingAreaPlacement causes fvwm to ignore
the concept of working area. The default WorkingAreaPlacement causes fvwm to
use the Working Area for window placement.

* MaximizeIgnoreWorkingArea / MaximizeUseWorkingArea /
	MaximizeUseDynamicWorkingArea
MaximizeUseWorkingArea causes fvwm to use the Working Area when you
maximize a window as MaximizeIgnoreWorkingArea causes fvwm to ignore
the concept of working area. The default MaximizeUseDynamicWorkingArea
cause to use the Dynamic Working Area when you maximize a window.

* FixedMaximizing / DynamicMaximizing
If the MaximizeUseDynamicWorkingArea (respectively, MaximizeUseWorkingArea)
style is used then when the (Dynamic) Working Area change the maximized
window are maximized again to respect the new area. FixedMaximizing
disabled this feature as DynamicMaximizing reestablish the default

* IgnoreWMStut / UseWMStrut
IgnoreWMStut cause fvwm to ignore the reserved space that an application ask
to fvwm for computing the Working Area. UseWMStrut (the default) causes fvwm2
to take in account this space in its computation.
 
Command:
-------

* EwmhNumberOfDesktop d
Where d is an integer > 0 and define the number of desktop you want to see
in a compliant pager. Note that this number is automatically updated
if you go to a Desk k > d. On the other hands, negative Desk are not
supported and can put some compliant pager and taskbar into big trouble.

* EwmhActivateWindow [cmd]
Where  cmd  is  a fvwm2 command (complex or builtin function) to be used
when a  compliant  application ask  to activate a window. The default is
is to Iconify Off, Focus and Raise. If no argument is given the default
is reestablished.

* EwmhFvwmStrut left right top bottom
Where left, right, top and bottom are  positive  or null integer which
represent an area in pixels from the left of the screen to left, from the
right  of the  screen to right, from the top of the screen to top and from
the bottom of the  screen  to  bottom. Default is 0 0 0 0.
This area define  an additional reserved space to the reserved space
defined by some applications.
You can override the Working area by using this command together
with the command "Style * IgnoreWmStrut"

* EwmhKdeSupport [bool]
Disable/Enabled special support for kde (On by default).
Maybe a style?

* EwmhGnomeSupport [bool]
Disable/Enabled special support for gnome (On by default)
Maybe a style?

Window Type Configuration:
-------------------------

This is problematic. I will come on this in an others email.

Regards, Olivier
--
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: Mikhael Goikhman <[email-masked]>
Date: Fri, 16 Nov 2001 23:07:19 +0000

> to be more careful with the manual page.

I mostly agree and am commenting only on names.

> New styles:

* IgnoreStayOnTopHints / UseStayOnTopHints for consistency?

> DoNotSetMiniIcon disable this feature and SetMiniIcon reestablish the

Other style names have prefix "dont". Also "supply" seems better to me.

* DontSupplyMiniIcon / SupplyMiniIcon

> style) but the icon window that can provide an application is ignored.

* DontSupplyIcon / SupplyIcon

Or maybe "donate" instead of "supply" and "Ewmh" prefix"? :)

* DontDonateEwmhIcon / DonateEwmhIcon

> cause to ignore only the ToolBar window type.

It may be 1) destructive, 2) compositive with "None" to reset, 3) with
complex syntax similar to BusyCursor. It is ok for me to use (1) or (2),
I don't know which one is less confusing.

> disabled this feature as DynamicMaximizing reestablish the default

* StaticMaximizing?

> to take in account this space in its computation.

* IgnoreWMStrut

> supported and can put some compliant pager and taskbar into big trouble.

* EwmhNumberOfDesktops

> is to Iconify Off, Focus and Raise. If no argument is given the default

* EwmhActivateWindowAction

Defaults to WindowListFunc?

> with the command "Style * IgnoreWmStrut"

* EwmhBaseStrut?

> Window Type Configuration:

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 19 Nov 2001 11:59:48 +0100

> to be more careful with the manual page.

Hm, it it really necessary to have a flood of new commands and
styles to fine tune everything?  I'd strip these options down
to not more than about five, e.g. enabling/disabling icon hints,
ewmh placement, ewmh stacking, window type, etc.  Being able to
prevent fvwm from setting EWMH hints itself doesn't look much
useful.  I can't imagine a situation where this would hurt.

Also, I suggest all EWMH related commands or styles start with the
string "EWMH".  E.g.:

  EWMHUseHints/EWMH/IgnoreHints
  EWMHUseIconHint/EWMHIgnoreIconHint
  EWMHUsePlacementHint/EWMHPlacementHint
  EWMHUseStackingOrderHint/EWMHIgnoreStackingOrderHint
  EWMHUseDecorationHint/EWMHIgnoreDecorationHint

> Disable/Enabled special support for gnome (On by default)

Yep, styles are better.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Olivier Chapuis <[email-masked]>
Date: Tue, 20 Nov 2001 08:49:38 +0100

On Mon, Nov 19, 2001 at 11:59:48AM +0100, Dominik Vogt wrote:
> styles to fine tune everything?

I think that one thing the users like with fvwm is that they
can configure it the way they want ("Do it your way").

> I'd strip these options down

The only styles I propose which say to fvwm to prevent from setting
EWMH hints itself are:

DoNotSetMiniIcon / SetMiniIcon, DoNotSetIcon / SetIcon

I think that this is useful because SetMiniIcon and SetIcon may
dramatically slow down windows mapping on machine with a visual !=
DirectColor || TrueColor (in this case there are width*height call
to XAllocColor, but maybe one can fix this).

> string "EWMH".  

Ok.

> E.g.:

So EWMHUseStackingOrderHint/EWMHIgnoreStackingOrderHint ?

> > if the application have no icon window and the IconOverride style is

Why the ForceEwmhIcon? Because it is the style *I* want :o)
So  EWMHMiniIconOverride / EWMHNoMiniIconOverride
and EWMHIgnoreEwmhIcon / EWMHForceEwmhIcon / EWMHUseEwmhIcon ???????

Or simply,

with EWMHUseIconHint = EWMHNoMiniIconOverride + EWMHForceEwmhIcon
and  EWMHIgnoreIconHint = EWMHMiniIconOverride + EWMHIgnoreEwmhIcon

It is ok for me (but for other users?).

> > * DoNotSetMiniIcon / SetMiniIcon

EWMHDoNotSetMiniIcon / EWMHSetMiniIcon, EWMHDoNotSetIcon / EWMHSetIcon

or simply:

EWMHDoNotSetIcon / EWMHSetIcon ?

or EWMHDontSupplyIcon / EWMHSupplyIcon or EWMHDontDonateIcon / EWMHDonateIcon ?

"ok" again (but for others users?).

> > and EwmhAnimate (the default) enable it.

If we have no such style default should be EwmhAnimate. I've no objection
to remove this one.

> > reestablish the default which is of course to use these hints

* EWMHIgnoreWMStateHints / EWMHUseWMStateHints
I think there is no objections for this one. I recall that WMState can
ask for: Maximize (Vertically and/or Horizontally), Shade, WindowListSkip,
stick, modal (I will come back on this state one day ...) and non standard
stacking states (not taken in account by the style). 

> > * IgnoreEwmhWindowTypeHints args

Forget this one should be considered with Window Type configuration.

> > use the Working Area for window placement.

So you suggest to have  EWMHUsePlacementHint/EWMHIgnorePlacementHint only?
Ah no, I see, EWMHUsePlacementHint/EWMHIgnorePlacementHint replaces 
IgnoreWMStut / UseWMStrut and we have no
WorkingAreaPlacement/ DynamicWorkingAreaPlacement / WorkingAreaPlacement
style and we use WorkingAreaPlacement as placement policy?
Yes this is ok (but if one want DynamicWorkingAreaPlacement).

> > disabled this feature as DynamicMaximizing reestablish the default

So you suggest to use EWMHUsePlacementHint/EWMHIgnorePlacementHint for
computing the (dynamic) working area and to use "DynamicMaximizing"?
But maybe some users will do not like to see its window to be remaximized
when a panel is hidden/unhidden.

> > is to Iconify Off, Focus and Raise. If no argument is given the default

Ok for EwmhActivateWindowAction.
Mikhael, I think  Iconify Off, Focus and Raise is better than the window
list function which warps to window (by default). Warping to the window
is natural for the window list as the window list disappear after you select
the window, but this is not the case with a taskbar.

> > * EwmhFvwmStrut left right top bottom

EWMHBasePlacementHint left right top bottom ?

> > Disable/Enabled special support for gnome (On by default)

Yes but it depends on what these commands do. At the present time
EwmhGnomeSupport does nothing (have to wait for a true first
alpha release of GNOME2). But maybe we never need such command if
we want to be ewmh compliant as it is a gtk/gnome developer which
really decides what should go into the spec (at least at the present
time). EwmhKdeSupport add support for
(i) the _KDE_NET_FRAME_STRUT hint (this hint should be set by the wm for
    each windows, it gives the size of the decoration)
(ii) Manage the KDE system tray (indicate which windows should be swallowed
     by a panel)
(iii) Some workaround for ksmserver

Maybe a style is better?

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 20 Nov 2001 12:24:58 +0100

> can configure it the way they want ("Do it your way").

Yes, but in some areas we should really take care that things
don't get too complicated.  I'm especially concerned about the
icon selection.  The code is very touchy right now and adding
three more styles may well make it unmaintainable.

> DoNotSetMiniIcon / SetMiniIcon,

Okay, I see no way to achieve this otherwise.  But keep in mind
that the user can change this style at any time and that fvwm must
then immediately change to the new behaviour.  This probably means
that the ewmh mini icon has to be stored at a different place than
the normal mini icon.  Remember that update.c and the related
function at the end of style.c has to be adapted.

> DoNotSetIcon / SetIcon

See below.

[snip]

> So EWMHUseStackingOrderHint/EWMHIgnoreStackingOrderHint ?

Yes.

> > > icon provided by the application.

See above.

> Why the ForceEwmhIcon? Because it is the style *I* want :o)

I don't see why we need the ...Icon styles.  The Ewmh icon is
just another way to specify an icon.  Currently there are three
ways an application can have an icon:  by fvwm style, by the
application using a pixmap and by the application using a window.
I'd just handle the Ewmh hint as a different way for the
application to specify the pixmap (or window?) that is preferred
to the normal icon hint.  The existing icon options would still
specify if the fvwm icon, or the application pixmap or window is
used.

> It is ok for me (but for other users?).

These two styles provide the same functionality as the five above.
It only really makes a difference if both, fvwm and the
application provided a mini icon.  In this case you can simply
fine tune the style.  The speed argument doesn't count here.

> "ok" again (but for others users?).

Hm, what is this functionality good anyway?  Why would fvwm want
to set the application's icon?  Only the application should use
the icon anyway.  I see no real need for this.

> If we have no such style default should be EwmhAnimate. I've no objection

I'd prefer to remove this one.  If you don't want animation, don't
use FvwmAnimate.

> stacking states (not taken in account by the style). 

Hm, when is fvwm meant to honour this hint?  Only when the window
becomes mapped?

> > > * Note on working area:
[snip]
> > > * NoWorkingAreaPlacement/ DynamicWorkingAreaPlacement / WorkingAreaPlacement
[snip]
> > > 	MaximizeUseDynamicWorkingArea
[snip]
> > > * FixedMaximizing / DynamicMaximizing
[snip]
> > > * IgnoreWMStut / UseWMStrut
[snip]

I'm not sure what to do about these.  I wondoer if fvwm would ever
be used *inside* Gnome or KDE.  If not, we'd just have to deal
properly with the hints the applications set.  The philosophy
behind a desktop environment and fvwm are a poor match.  The fvwm
user expects that applications 'do as I want' while the Gnome/KDE
developers expect that applications 'do what the application
programmer does'.  My few attempts to get fvwm running under
either failed utterly - they simply assume that the window manager
does nothing else but draw windows.

> > > in a compliant pager.

I think we can't get around this one.

> > > Note that this number is automatically updated
> > > if you go to a Desk k > d.

I wouldn't do that.  Our own pager doesn't react to new desks
either.

> > > On the other hands, negative Desk are not

Yeah, I can remember the discussion about negative desks.  The
majority of the wm-spec list thought them to be useless and so
made an unnecessary limitation :-(

> the window, but this is not the case with a taskbar.

Yes, a function in the style of WindowListFunc should do.  I'd
call it EwmhActivateWindowFunc.
                          ^^^^

> EWMHBasePlacementHint left right top bottom ?

If you ask me: let's ignore struts altogether and focus on
enhancing the placement algorithms in fvwm.  Or maybe the struts
could be used as an area with a higher placement penalty.  Then
the EwmhUse/IgnorePlacemntHint styles could be used.

> time).

> EwmhKdeSupport add support for

Argh! So much about standards.  In this case, I'd rather ignore
Gnome/KDE specific hints altogether until is starts hurting ;-)

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 20 Nov 2001 17:09:26 +0100

> three more styles may well make it unmaintainable.

I just read the icons code it is not so complex (the bug I introduce
was a big mistake: I forget a break in a case switch; the bug does not
come because I was unable to read the code).

[ snip, snip ]

> fine tune the style.  The speed argument doesn't count here.

I am not sure to understand. However note that the above styles
allow automatic config: I do not like most of the icon that are
provided by the "X" applications, as I like the KDE (ewmh) icon.
So I am happy with Style * IconOverride, EWMHForceEwmhIcon
and I do not want to type a never finished list of lines like:

Style * IconOverride
Style "kapp1" NoIconOverride
Style "kapp2" NoIconOverride
...
Style "gapp1" NoIconOverride
Style "gapp2" NoIconOverride
...

The same remark apply with mini icon.

> the icon anyway.  I see no real need for this.

It is one of the most useful feature of *our* ewmh implementation.
Of course this is out of the spec. The point is that allows to have
the same mini icon in the menu, in the window list, in the various
modules *and* in any compliant application. The same apply to icon
(some compliant application prefer a big icon).
Maybe one day a user would want that complaints application do not
use the ewmh (mini) icon that provide the app but the one that
provide the Icon or/and MiniIcon style command. So here in fact we may
want to add an Override style!
Moreover, now I think it is not a good idea to have only
"one" style. Really I prefer:

EWMHDontDonateMiniIcon / EWMHDonateMiniIcon
EWMHDonateIcon / EWMHDontDonateIcon

> Hm, when is fvwm meant to honour this hint?  Only when the window

fvwm should honor this hint at window mapping. Then, it must maintain
the _NET_WM_STATE to the *real* window state. Moreover, fvwm can receive
a _NET_WM_STATE Client Message (typically a compliant taskbar may ask
to shade a window) I do not think it is a good idea to reject such a
client message as it is probably the user that ask to put the window
in the asked states.

> does nothing else but draw windows.

At present time I use fvwm inside KDE2 (I know some users which
do that with fvwm-ewmh and which are happy). There are users which
use fvwm inside GNOME1 or which use the GNOME1 panel only.
Of course if we do not try to do so that fvwm can run inside
KDE2+ or GNOME2+ this will be always a mess.
Note that kwin is GUI configurable but absolutely not configurable
as fvwm. Moreover kpager is very weak (and the future GNOME2 pager
will be probably weak) compared to FvwmPager. So users which
like .fvwm2rc and want "a panel" (kicker)  and/or a desktop
application (yes some users want such app!) and/or a session manager
and/or use certain KDE app which work better together with one of the
above app will use fvwm and not kwin.
What I propose is: use fvwm with GNOME/KDE and you will be able to do
"as you want". 

> Gnome/KDE specific hints altogether until is starts hurting ;-)

For me  the _KDE_NET_FRAME_STRUT is very important: I know only
one application which use it, it is amor, it is a small smiley which
go around the windows, my 22 months daughter like it a lot :o) 

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 20 Nov 2001 18:49:36 +0100

On Tue, Nov 20, 2001 at 05:09:26PM +0100, Olivier Chapuis wrote:
> [ snip, snip, snip ]

Nope, you only have to override the ugly icons as always:

  Style * IconOverride
  Style app_with_ugly_icon1 Icon my_pretty_icon.xpm
  Style app_with_ugly_icon2 Icon my_pretty_icon.xpm
  ...

> (some compliant application prefer a big icon).

But it's still only a hack if it's nor part of the spec.  The
application may reset that value at any time and void our efforts.

> EWMHDontDonateMiniIcon / EWMHDonateMiniIcon

Might work for mini icons,

> EWMHDonateIcon / EWMHDontDonateIcon

but for regular icons this is way too far off any spec.  A decent
window manager should really not fiddle with the application's
data.

> client message as it is probably the user that ask to put the window

In my experience it is far more often a funny application that
sends these commands than a taskbar or whatever.  If things
continue to work our as they do at the moment, suppressing these
requests (or just some of them) may very well become a reasonable
default soon.

[snip]

> go around the windows, my 22 months daughter like it a lot :o) 

:)  But still, once we've improved the placement algorithms, you
can just set the penalty high enough and get the same effect, but
can still override it manually without digging obscure
configuration menus:

  Style amor PlacementOverlapPenalty 1000000

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 21 Nov 2001 12:14:15 +0100

> the EwmhUse/IgnorePlacemntHint styles could be used.

Yes, I will add  a PlacementOverlapPenalty style. But I think we
should use Strut here as the ewmh working area may be use for the
maximizing cmd (and perhaps for the IconBox style). Moreover, I do
not see a big difference between
(i) use the working area in the placement algo
(ii) put an "infinite" penalty for the complement of the working
area
but the fact that (ii) will not apply for Cascade and Random placement
and that (i) is totally trivial to implement (is implemented :o).
On the other hands, we may want to add a
	PlacementPenaltyBox geometry penalty
cmd or style, I do not know (nothing precise here).

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 21 Nov 2001 07:33:56 +0100

>   Style app_with_ugly_icon2 Icon my_pretty_icon.xpm

Yes, I think with fvwm-themes/wm-icons config scheme in head
which defines wm-icons icons for most of the KDE application.
We should fix the things in fvwm-themes/wm-icons by splitting
the icon lists.
 
> window manager should really not fiddle with the application's

No, No, No. I propose to set an ewmh icon for app that does not provide
one. There is nothing in the spec that forbid this. I do *not* propose the
Override style I just say that maybe one day a user will ask such style.
Anyway, this is technically possible (and implemented in fvwm-ewmh):
if an application change or rest its ewmh icon it should send a 
_NET_WM_ICON Property Notify message, so we can reoverride it (but
this may lead to unacceptable competition so again I do not propose
this).

Moreover, the spec ask to play with application data: some application
properties (e.g., _NET_WM_STATE, _NET_WM_DESKTOP,  _NET_WM_VISIBLE_NAME)
must or should be set by the wm (as with some GNOME1 hint). Some others
window properties must or should be set by the application (e.g., 
_NET_WM_NAME, _NET_WM_STRUT). For _NET_WM_ICON nothing is said about who
should set it. Of course it is implicitly assumed that it is the app
that should/may (?) set it. Anyway, for app which dose not provide one
I do not see why the wm should not.

Finally, I do not see why we should not implement a feature because
it is not in the spec. The ewmh spec is far from being a bible.

> requests (or just some of them) may very well become a reasonable

I use the "ewmh spec" since 7 months now (with fvwm-ewmh). I never
see an application which do a funny thing with its _NET_WM_STATE
after mapping.
But I am agree that this may happen one day. So we may have

* EWMHIgnoreInitialWMStateHints / EWMHUseInitialWMStateHints
* EWMHIgnoreRunningWMStateHints / EWMHUseRunningWMStateHints

and this style may have args: a space separted list of states?

Or a more general:

* EWMHIgnoreInitialHints [args] / EWMHUseInitialHints [args]
* EWMHIgnoreRunningHints [args] / EWMHUseRunningHints [args]

where args is a space separated list of ewmh state and other hints
as the Desktop, the strut, ..etc.

>   Style amor PlacementOverlapPenalty 1000000

No, this hint have noting to do with placement. Amor need to know
the size of the border and title height of the windows to go arround it
(e.g., to jump onto the title bar and not on the top of the
"interior" of the window).

Olivier