On Thu, Dec 20, 2001 at 10:22:56PM +0100, Olivier Chapuis wrote:
> 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, ...
Yes, of course *if* you interpret everything as a starting state,
then its perfectly okay. But one major idea behind fvwm is that
everything is configurable at run time, not at start time. I am
still determined to remove the Recapture command one day.
Introducing new features that are not configurable at run time
works against this greater goal.
> 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).
Well, I find this argument rather unfair. I have spent a *lot* of
time cleaning up fvwm's code over the past few years. I do likely
90% of the debugging, not because I'm fond of debugging, but
because nobody else does it. Of course I'd rather write fancy
features, myself.
> 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.
No problem here. These can easily be changed without fiddling
with styles.
> 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.
Agreed.
> 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???
If you interpret "EWMHUseStateHints" as "EWMH state hints override
other user preferences" the question is easy to answer:
a) With EWMHUseStateHints set, the states specified in the hint
override any other style commands.
b) To be able to do the switching properly and maintain the
state atom on the window at the same time, fvwm must not
operate directly on the atom but keep a local copy of the
current states and of the original states.
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]
