On Mon, Dec 17, 2001 at 01:27:29AM +0100, Olivier Chapuis wrote: > On Sun, Dec 16, 2001 at 05:56:48PM +0100, Dominik Vogt wrote: > > 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? > > 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.
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 > 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?? 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. > 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.). This is *not* about states but about styles. Style * Sticky issued at run time does not affect any already mapped windows. > 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. 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. > > 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? > > > 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. Later. 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]
