Subject: Question about ewmh implementation

From: Dominik Vogt <[email-masked]>
Date: Sun, 16 Dec 2001 17:56:48 +0100

As far as I understand the code in ewmh.c, the ewmh state hints
modify the style used by a window.  Now, if the user uses the
"EWMHUseStateHints" or "EWMHIgnoreStateHints", do windows reflect
that change without a recapture as with all other styles?  I can
remember that this was far from being trivial for the GNOME hints.
The main problem was, that the code in update.c only handles
styles that have the 'changed' flag set (with one of the SCSET_...
macros).  But this is only the case for the 'IGNORE_STATE_HINTS'
style, not the ones controlled by it like 'sticky'.

Olivier, can you define a set of tests to verify the ewmh
functionality?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Mon, 17 Dec 2001 01:27:29 +0100

On Sun, Dec 16, 2001 at 05:56:48PM +0100, Dominik Vogt wrote:
> that change without a recapture as with all other styles?  

In fact EWMHUseStateHints and EWMHIgnoreStateHints are only
used at window mapping: if a new window come with some
_NET_WM_STATE states with EWMHIgnoreStateHints these states
are ignored; that's all so it does not seem that there are
problems with style update here. However, after the window has
been initialized it is fvwm2 which sets and maintains the
_NET_WM_STATE states. So if we want to be dynamic here we
must store the initial _NET_WM_STATE states in the FvwmWindow
structure to be able to restore/erase these states. This
seems not reasonable for me. No??
Moreover, any applications can send a message to change
the state of a window (and other things as the Current
desktop, the current view port, the active window ..etc.).
The problem here is that any application can send a message
and it is impossible to know which app send the message.
So, at present time all the messages are accepted because I
think that for 99% of the cases such messages are sent by the
users (via an ewmh compliant pager or taskbar). Of course we
can add a style as:
   Style "match" EWMHIgnoreClientMessage
that causes fvwm2 to ignore ewmh client messages which concerns
windows which match "match". I can do that if you think that
this may be useful (no dynamic update problem here I think).
In fact, the good behavior of the previous style is to
cause fvwm2 to ignore client messages send by an app whose
main window match "match". This is not possible ...
Finally, some problems similar to those you mention may arise
with the _NET_WINDOW_TYPE types, but at present time nothing
here is configurable as I we need some discussions on styles
(conditional styles) which are postponed.

> I can
What do you mean exactly? Here some possible answer.

I've written a file a la tests/purify/purify.fvwm2rc for all the
new commands and styles I've introduced recently I will merge it
one days.
I can write a test program but there are already some: just install
kde version 2 or 3 and run fvwm2 with any kde app, kicker, kpager
and/or kdesktop or even run ksmserver with fvwm2 as window manager.
I can give some tips to do so. Everything seem to work fine but a
few problems (as menu in kde app with no focus, saving/starting a
session on a "right" page (as for GNOME1)).
Also last week I have compiled GNOME2 (from the glib2 to gnome-core
+ nautilus "2" and it ewmh desktop). It is not usable but it seems
that fvwm is GNOME2 compliant. Also, gtk+-2 is usable and there is
a library "libwnck" (the gnome library for writing pager and
taskbar) which has some tests programs.
So, what we may need is a FvwmScript or a menu that allows to easily
test all the possibility. But the fvwm2 man page plus a FvwmConsole
is not so bad.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 17 Dec 2001 11:20:13 +0100

On Mon, Dec 17, 2001 at 01:27:29AM +0100, Olivier Chapuis wrote:
> problems with style update here.

I agree that _NET_WM_STATE is used only at map time, but
EWMHIgnoreStateHints is a normal style and should be treated as
such, i.e. honoured immediately when the style line is issued.

> However, after the window has

I wouldn't update the _NET_WM_STATE at all if EWMHIgnoreStateHints
is used.  But let's have a look at the styles that are set in
ewmh.c:

  Layer
  Sticky
  FixedPosition
  WindowListSkip
  CirculateSkip
  NoTitle
  (focus policy)
  GrabFocus
  ClickToFocusPassesClick
  ClickToFocusRaises
  BorderWidth
  HandleWidth

This depends entirely on the window type, so as long as fvwm
remembers the window type, it can always restore the proper styles
when EWMHUseStateHints is issued again.  All styles except Layer
and Sticky (which are states after the window is mapped) should
really be ignored when EWMHIgnoreStateHints is used at run time.

> desktop, the current view port, the active window ..etc.).

This is *not* about states but about styles.

  Style * Sticky

issued at run time does not affect any already mapped windows.

> (conditional styles) which are postponed.

As far as I can see, styles are only modified in response to the
value of _NET_WINDOW_TYPE.  To make this clear: I'm only concerned
about styles not being applied immediately, nothing else.

> test all the possibility. But the fvwm2 man page plus a FvwmConsole

Later.

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: Wed, 19 Dec 2001 17:34:55 +0100

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

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 20 Dec 2001 12:05:06 +0100

>   _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.

> 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 ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 20 Dec 2001 22:22:56 +0100

On Thu, Dec 20, 2001 at 12:05:06PM +0100, Dominik Vogt wrote:
> > [snip]

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

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 21 Dec 2001 10:53:17 +0100

On Thu, Dec 20, 2001 at 10:22:56PM +0100, Olivier Chapuis wrote:
> 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
> of the initial _NET_WM_STATE states.
>
> But I am agree that some

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.

> not affected by EWMHIgnoreStateHints/EWMHUseStateHints switching.

No problem here.  These can easily be changed without fiddling
with styles.
 
> EWMHUseStateHints switching.

Agreed.

> But what to do in the following
> situation:
> EWMHIgnoreStateHints, and after EWMHUseStateHints.
>
> Do the

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 ^_^  ^_^