On Wed, Dec 19, 2001 at 05:34:55PM +0100, Olivier Chapuis wrote:
> 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?
No. For example, you mentioned the skip list hints and the
'modal' hint. EWMHIgnoreStateHints/EWMHUseStateHints should
definitely turn these on and off. The rule of thumb is: if you
need to restart fvwm or recapture the window to get the desired
effect, then you're doing something wrong. This is not critical
for the sticky and staysontop hints because there are commands in
to switch the state without modifying the style.
> ii. Do someone want an EWMHIgnoreClientMsg style?
Yes and no: yes, the user needs control over what the application
can and can not do. No, this doesn't need to be EWMH specific.
There are already styles like FixedPPosition and FixedPSize. I
guess the user won't care if the application moves its own windows
with GNOME hints, EWMH hints or X calls. If there is something
that an application can request of its own (shade, maximize,
stick, etc.) there should be a way for the user to forbid this
state transition - and only this. So I guess we need a number of
new styles controlling every single of these state stransitions,
but they do not need an "EWMH" in their name.
> 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)
Yes. Just don't forget that the user must be able to switch on
and off the window type handling at any time without restarting.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
