I am a bit lost. I try to restart the discussion.
There is two ewmh hints that affect the style of a window at
mapping: (1) _NET_WM_STATE and (2) _NET_WINDOW_TYPE
a window map with these hints set or not.
(1) _NET_WM_STATE
the possible state are: hidden (iconified), shaded, maximized
(vertically or/and horizontally), modal, sticky, in pager skip list,
in taskbar skip list, stay on top.
(a) window mapping
At present time fvwm ignore shaded and maximize states (as
for gnome hints, because there is no such style); the pager
skip list and the task bar skip list are considered as the
same hint (= fvwm skip list); modal is ignored (this should
be configured by the user: Style (Condition=modal, ...) styles-arg,
but if someone has some idea for some default styles-arg we can
do something) and the other states are respected using styles
(overriding the "default" style).
So here I think that, hidden == start iconic, sticky = start sticky,
...etc and that EWMH{Use,Ignore}State should do nothing for already
mapped window. Moreover stay on top have a special style (as it is
not standard: EWMH{Use,Ignore}StackingOrder).
(b) window life
After window mapping _NET_WM_STATE take an other signification:
it set and maintained by fvwm2 to the *real* state. I see no
reason why we should not maintain this.
(c) client message
Finally any application can use the _NET_WM_STATE to send
client messages to fvwm2. Here it will be good to be able to
reject some of the client message, but there is no way
to do this in a good way (by selecting the sender).
So (a), (b) and (c) are really different things. EWMHIgnoreState
concern only (a) (_NET_WM_STATE hints are ignored) and I do not
think that it should concern (b) and (c). But, I can add a
EWMHIgnoreClientMsg style for (c) which will cause fvwm2 to
ignore others messages (as current desktop change).
Now about (b). One may want that _NET_WM_STATE not to be maintained
by fvwm2, because this not useful: no ewmh application around
(this is the only reason I see). In this case what I can do
is a global command (or a style ??) EWMHSupport On/Off that
will disable all the ewmh patch at run time.
So, here 3 questions as an answer:
i. are you finally agree with my interpretation of the
_NET_WM_STATE hints as starting style?
ii. Do someone want an EWMHIgnoreClientMsg style?
iii. Do someone want an EWMHSupport On/Off cmd?
Note: there is also _NET_WM_DESKTOP which works as _NET_WM_STATE
for the desktop number of the window. In the discussion I consider
this hint as a _NET_WM_STATE hint (and need to fix one or two things
about this in the code!).
(2) _NET_WINDOW_TYPE:
This is work in progress! At present time nothing is configurable
here. As for _NET_WM_STATE styles are used (in ewmh.c, as fvwm2
handle _NET_WM_STATE hints in ewmh_events.c) and every thing
is hard coded (so that fvwm2 works with KDE version >= 2 as it is
the only working set of apps which use the ewmh spec.).
A _NET_WINDOW_TYPE type is only a conceptual description of
the application it is set by the app before mapping and never
change. As it is a conceptual description nothing is really
clear of what to do for a given type (and I am sure that
it will have some conflicts between KDE and GNOME about the
meaning of some types). So here we need conditional style:
Style (Condition=A_Window_Type, ...) args
or
AddToFunc StyleFunction
+ I All (Condition=A_Window_Type, ...) WindowStyle args
if I well understand Tim. Moreover, ConfigFvwmDefaults will
contains our interpretation of the various types. So,
for _NET_WINDOW_TYPE everything will be totally dynamic :o)
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
