On Thu, Dec 20, 2001 at 12:05:06PM +0100, Dominik Vogt wrote:
> 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).
> > 
> > [snip]
> > 
> >   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.
> 

I do not understand your sentence:  "if you need to restart fvwm or
recapture the window to get the desired effect, then you're doing
something wrong". If we interpret the _NET_WM_STATE states as
starting state, a recapture (or a restart) should do nothing
on the window regarding the initial _NET_WM_STATE states of the window
and the EWMHIgnoreStateHints/EWMHUseStateHints styles (used before or
after window mapping). For a pure fvwm example: with
Style xcalc StartIconic, start an xcalc, it is iconified. If you type
Style xcalc StartNormale (~ ignore StartIconic) your xcalc is still
iconified. Or if you uniconify the window, a recapture or a restart
does not iconify the xcalc.
 
So I do not thing that the EWMHIgnoreStateHints/EWMHUseStateHints
styles are wrong at present time this is a pb. of interpretation
of the initial _NET_WM_STATE states. But I am agree that some
states (maybe all) can be interpreted as non only starting state.
In fact I don't care, it leads to complicated codes and new entries
in the FvwmWindow structure for almost nothing (and I am afraid to
lost my time in the place of doing more interesting things as completing
the EWMH support, help with conditional style, added gettext support,
...etc).
Moreover, I've interpreted the _NET_WM_STATE_STAYS_ON_TOP this
way (I am bit paranoid with stays on top hints) EWMHIgnoreStackingHints /
EWMHUseStackingHints update the layer of the window if a window map
with _NET_WM_STATE_STAYS_ON_TOP (and no layer styles are applied to
the window).

So Let says that:

_NET_WM_STATE_HIDDEN = StartIconic
_NET_WM_STATE_STICKY = StartSticky
_NET_WM_STATE_SHADED = StartShaded         <-- not implemented
_NET_WM_STATE_MAXIMIZED_HORIZ = StartMaximized on 100 0 <-- ""
_NET_WM_STATE_MAXIMIZED_VERT = StartMaximized on 0 100  <-- ""
_NET_WM_STATE_MAXIMIZED_HORIZ + _NET_WM_STATE_MAXIMIZED_VERT = 
        StartMaximized on 100 100           <-- ""
_NET_WM_DESKTOP d = StartsOnDesk d          <-- implemented in my machine

states are applied only at window mapping (if EWMHUseStateHints)
and these state are ignored during a recapture or a restart and are
not affected by EWMHIgnoreStateHints/EWMHUseStateHints switching.

And the windows with

_NET_WM_STATE_STAYS_ON_TOP = StaysOnTop (style)
_NET_WM_STATE_MODALE = ???
_NET_WM_STATE_SKIP_PAGER = _NET_WM_STATE_SKIP_TASKBAR =
        WindowSkipList

initial hints should be affected by  EWMHIgnoreStateHints / 
EWMHUseStateHints switching. But what to do in the following
situation:
a window start with _NET_WM_STATE_SKIP_TASKBAR and EWMHUseStateHints
so it is in the fvwm windowskiplist, now by a style cmd
it is removed from the windowskiplist, after the user apply
EWMHIgnoreStateHints, and after EWMHUseStateHints. Do the
window has to be in the fvwm windowskiplist? More generally,
if a window has an initial _NET state and if the user interactes
with this _NET state with a fvwm command or a style does the
_NET state should be erased for ever?

In the opposed direction, if have

Style <pattern> WindowListHit
Style <pattern> EWMHUseStateHints

and after that a window which match <pattern> map with
_NET_WM_STATE_SKIP_TASKBAR, do we have to put it in the
fvwm  windowskiplist? I would say no, but this is not done
in the current code for simplicity ... Do we have to do
things like this???

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]

Reply via email to